Skip to content
Snippets Groups Projects
New look: Off

[samsung-n5110][samsung-jflte] dhcpcd not working

    • Closed Imported Issue created by Administrator @root

    On the Samsung Galaxy Note 8.0, dhcpcd does not seem to work:

    note8:~# dhcpcd wlan0
DUID 00:01:00:01:22:0e:08:1f:00:90:4c:c5:12:38
wlan0: IAID 4c:c5:12:38
wlan0: rebinding lease of 192.168.0.21
wlan0: soliciting an IPv6 router
wlan0: probing for an IPv4LL address
wlan0: DHCP lease expired
wlan0: soliciting a DHCP lease
wlan0: offered 192.168.0.21 from 192.168.0.1
wlan0: probing address 192.168.0.21/24
wlan0: using IPv4LL address 169.254.122.114
ipv4_addaddr: if_addaddress: Invalid argument
wlan0: leased 192.168.0.21 for 86400 seconds
ipv4_addaddr: if_addaddress: Invalid argument
wlan0: no IPv6 Routers available
timed out
dhcpcd exited

    The busybox dhcp client (udcpc) works without any problems. However, as pmOS (postmarketos-base to be precise) depends on networkmanager/dhcpcd now, the busybox ifup function no longer uses udhcpc but dhcpcd. Therefore, afaik, there is no easy way to use udhcpc instead of dhcpcd.

    Edited
    To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information

    Child items 0

    • No child items are currently assigned. Use child items to break down this issue into smaller parts.

    Activity

    • Administrator
      Administrator @root · Imported
      Author Owner

      Created by: ollieparanoid

      Thanks for reporting! It should be possible to configure NetworkManager to use another DHCP client: https://wiki.archlinux.org/index.php/NetworkManager#Problems_with_internal_DHCP_client

      Could you check if that works?

      By * postmarketOS Bot on 2018-05-05T13:34:23

    • Administrator
      Administrator @root · Imported
      Author Owner

      Dhclient seems to work. The current NetworkManager build for armhf does not support dhclient, however. A new build with dhclient support should arrive soon (see networkmanager in Alpine). Building NetworkManager using the pmOS build environment results in a broken NetworkManager binary, the binary does not define any dynamic symbols but these are required for loading plugins (which are required for wifi).

      By Michael Hamann on 2018-05-11T20:41:46

    • Administrator
      Administrator @root · Imported
      Author Owner

      Created by: ollieparanoid

      This is weird, I've opened pmbootstrap#1488 (closed) to track this.

      By * postmarketOS Bot on 2018-05-12T19:37:20

    • Administrator
      Administrator @root · Imported
      Author Owner

      Alpine has the new version of NetworkManager for armhf now which has dhclient support. Unfortunately, however, this does not solve this problem. NetworkManager now successfully obtains an IP address and marks the connection as "connected" but in fact setting the IP address fails:

      Jan  1 01:59:59 note8 daemon.warn NetworkManager[2293]: <warn>  [1526580939.3319] platform-linux: do-add-ip4-address[8: 192.168.0.21/24]: failure 22 (Invalid argument)

      Apparently NetworkManager only gets the IP from dhclient and uses an internal method to set it. Calling dhclient wlan0 afterwards successfully assigns an IP address.

      By Michael Hamann on 2018-05-17T18:23:36

    • Administrator
      Administrator @root · Imported
      Author Owner

      Created by: ollieparanoid

      Cool that you've tried it out! Could you check if #1499 (closed) fixes this (possibly in combination with using dhclient)?

      By * postmarketOS Bot on 2018-05-17T22:12:21

    • Administrator
      Administrator @root · Imported
      Author Owner

      I did already disable mac address randomization before because I saw in the log that it failed. Further, I also added my user to the plugdev group as that was already mentioned in the update message for the new NetworkManager package. So no, unfortunately, that's no fix.

      By Michael Hamann on 2018-05-18T17:55:05

    • Administrator
      Administrator @root · Imported
      Author Owner

      Created by: ollieparanoid

      Alright, some more ideas:

      1. Try this fix.
      2. The dhcpcd error comes from ipv4_addaddr() after calling if_address(). As I understand, some Linux syscall gets called in the latter function, which sets the "Invalid argument" error. You could find the syscall, and read its documentation - my guess is, that either there is a kernel option needed to make the syscall work as intended, or that your kernel has it broken for some reason (and you could fix it by comparing to other kernels).
      3. Read the manual of /etc/dhcpcd.conf and /etc/dhclient.conf and play with the configuration values.
      4. Dig into the source of NetworkManager and find out why dhclient fails when called from Networkmanager, but not when called manually (I guess it calls it in a different way?).

      By * postmarketOS Bot on 2018-05-20T13:39:34

    • Administrator
      Administrator @root · Imported
      Author Owner

      Thank you very much for these tips! Trying the second option, I got the following excerpt from an strace of a dhcpcd call which should be the failing call where it tries to set the IP address:

      sendmsg(6, {msg_name={sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, msg_namelen=12, msg_iov=[{iov_base={{len=48, type=0x14 /* NLMSG_??? */, flags=NLM_F_REQUEST|NLM_F_ACK|0x500, seq=24, pid=0}, "\x02\x18\x00\x00\x08\x00\x00\x00\x08\x00\x02\x00\xc0\xa8\x00\x15\x08\x00\x04\x00\xc0\xa8\x00\xff\x08\x00\x08\x00\x00\x02\x00\x00"}, iov_len=48}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 48
recvmsg(6, {msg_name={sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, msg_namelen=12, msg_iov=[{iov_base={{len=68, type=NLMSG_ERROR, flags=0, seq=24, pid=4294963176}, {error=-EINVAL, msg={{len=48, type=0x14 /* NLMSG_??? */, flags=NLM_F_REQUEST|NLM_F_ACK|0x500, seq=24, pid=0}, "\x02\x18\x00\x00\x08\x00\x00\x00\x08\x00\x02\x00\xc0\xa8\x00\x15\x08\x00\x04\x00\xc0\xa8\x00\xff\x08\x00\x08\x00\x00\x02\x00\x00"}}}, iov_len=2816}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, MSG_PEEK|MSG_TRUNC) = 68
recvmsg(6, {msg_name={sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, msg_namelen=12, msg_iov=[{iov_base={{len=68, type=NLMSG_ERROR, flags=0, seq=24, pid=4294963176}, {error=-EINVAL, msg={{len=48, type=0x14 /* NLMSG_??? */, flags=NLM_F_REQUEST|NLM_F_ACK|0x500, seq=24, pid=0}, "\x02\x18\x00\x00\x08\x00\x00\x00\x08\x00\x02\x00\xc0\xa8\x00\x15\x08\x00\x04\x00\xc0\xa8\x00\xff\x08\x00\x08\x00\x00\x02\x00\x00"}}}, iov_len=2816}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 68
writev(2, [{iov_base="ipv4_addaddr: if_addaddress: Inv"..., iov_len=45}, {iov_base=NULL, iov_len=0}], 2ipv4_addaddr: if_addaddress: Invalid argument) = 45

      The kernel interface that is called here is rnetlink. I have no idea though what's wrong here or where in the kernel this message is handled. Here is a complete strace of setting the same IP address using ip (which sucessfully assigns the IP address):

      execve("/sbin/ip", ["ip", "addr", "add", "192.168.0.21/24", "dev", "wlan0"], 0xbeeb1d64 /* 16 vars */) = 0
set_tls(0x401ab54c)                     = 0
set_tid_address(0x401ab4c4)             = 18253
mprotect(0x400f4000, 8192, PROT_READ)   = 0
getuid32()                              = 0
socket(AF_NETLINK, SOCK_RAW, NETLINK_ROUTE) = 3
bind(3, {sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, 12) = 0
getsockname(3, {sa_family=AF_NETLINK, nl_pid=18253, nl_groups=00000000}, [12]) = 0
clock_gettime(CLOCK_REALTIME, {tv_sec=1526895595, tv_nsec=791265094}) = 0
sendto(3, "\24\0\0\0\22\0\1\3\354\223\2[\0\0\0\0\0\0\0\0", 20, 0, {sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, 12) = 20
brk(NULL)                               = 0x400f7000
brk(0x400fa000)                         = 0x400fa000
recvmsg(3, {msg_name={sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, msg_namelen=12, msg_iov=[{iov_base=[{{len=996, type=0x10 /* NLMSG_??? */, flags=NLM_F_MULTI, seq=1526895596, pid=18253}, "\x00\x00\x04\x03\x01\x00\x00\x00\x49\x00\x01\x00\x00\x00\x00\x00\x07\x00\x03\x00\x6c\x6f\x00\x00\x08\x00\x0d\x00\x00\x00\x00\x00"...}, {{len=992, type=0x10 /* NLMSG_??? */, flags=NLM_F_MULTI, seq=1526895596, pid=18253}, "\x00\x00\x08\x03\x02\x00\x00\x00\x80\x00\x00\x00\x00\x00\x00\x00\x09\x00\x03\x00\x73\x69\x74\x30\x00\x00\x00\x00\x08\x00\x0d\x00"...}, {{len=1016, type=0x10 /* NLMSG_??? */, flags=NLM_F_MULTI, seq=1526895596, pid=18253}, "\x00\x00\x01\x03\x03\x00\x00\x00\x80\x00\x00\x00\x00\x00\x00\x00\x0c\x00\x03\x00\x69\x70\x36\x74\x6e\x6c\x30\x00\x08\x00\x0d\x00"...}], iov_len=8192}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 3004
recvmsg(3, {msg_name={sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, msg_namelen=12, msg_iov=[{iov_base=[{{len=976, type=0x10 /* NLMSG_??? */, flags=NLM_F_MULTI, seq=1526895596, pid=18253}, "\x00\x00\x00\x02\x04\x00\x00\x00\x90\x10\x00\x00\x00\x00\x00\x00\x0b\x00\x03\x00\x72\x6d\x6e\x65\x74\x30\x00\x00\x08\x00\x0d\x00"...}, {{len=976, type=0x10 /* NLMSG_??? */, flags=NLM_F_MULTI, seq=1526895596, pid=18253}, "\x00\x00\x00\x02\x05\x00\x00\x00\x90\x10\x00\x00\x00\x00\x00\x00\x0b\x00\x03\x00\x72\x6d\x6e\x65\x74\x31\x00\x00\x08\x00\x0d\x00"...}, {{len=976, type=0x10 /* NLMSG_??? */, flags=NLM_F_MULTI, seq=1526895596, pid=18253}, "\x00\x00\x00\x02\x06\x00\x00\x00\x90\x10\x00\x00\x00\x00\x00\x00\x0b\x00\x03\x00\x72\x6d\x6e\x65\x74\x32\x00\x00\x08\x00\x0d\x00"...}], iov_len=8192}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 2928
recvmsg(3, {msg_name={sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, msg_namelen=12, msg_iov=[{iov_base=[{{len=1000, type=0x10 /* NLMSG_??? */, flags=NLM_F_MULTI, seq=1526895596, pid=18253}, "\x00\x00\x01\x00\x07\x00\x00\x00\x02\x10\x00\x00\x00\x00\x00\x00\x09\x00\x03\x00\x70\x32\x70\x30\x00\x00\x00\x00\x08\x00\x0d\x00"...}, {{len=1004, type=0x10 /* NLMSG_??? */, flags=NLM_F_MULTI, seq=1526895596, pid=18253}, "\x00\x00\x01\x00\x08\x00\x00\x00\x43\x10\x01\x00\x00\x00\x00\x00\x0a\x00\x03\x00\x77\x6c\x61\x6e\x30\x00\x00\x00\x08\x00\x0d\x00"...}, {{len=1004, type=0x10 /* NLMSG_??? */, flags=NLM_F_MULTI, seq=1526895596, pid=18253}, "\x00\x00\x01\x00\x09\x00\x00\x00\x03\x10\x00\x00\x00\x00\x00\x00\x0b\x00\x03\x00\x72\x6e\x64\x69\x73\x30\x00\x00\x08\x00\x0d\x00"...}], iov_len=8192}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 3008
recvmsg(3, {msg_name={sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, msg_namelen=12, msg_iov=[{iov_base={{len=20, type=NLMSG_DONE, flags=NLM_F_MULTI, seq=1526895596, pid=18253}, 0}, iov_len=8192}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 20
socket(AF_UNIX, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 4
ioctl(4, SIOCGIFINDEX, {ifr_name="wlan0", }) = 0
close(4)                                = 0
sendmsg(3, {msg_name={sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, msg_namelen=12, msg_iov=[{iov_base={{len=40, type=0x14 /* NLMSG_??? */, flags=NLM_F_REQUEST|NLM_F_ACK|0x600, seq=1526895597, pid=0}, "\x02\x18\x00\x00\x08\x00\x00\x00\x08\x00\x02\x00\xc0\xa8\x00\x15\x08\x00\x01\x00\xc0\xa8\x00\x15"}, iov_len=40}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 40
recvmsg(3, {msg_name={sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, msg_namelen=12, msg_iov=[{iov_base={{len=36, type=NLMSG_ERROR, flags=0, seq=1526895597, pid=18253}, {error=0, msg={len=40, type=0x14 /* NLMSG_??? */, flags=NLM_F_REQUEST|NLM_F_ACK|0x600, seq=1526895597, pid=0}}}, iov_len=8192}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 36
exit_group(0)                           = ?
+++ exited with 0 +++

      The last sendmsg call here is very similar to the one above, one can see the IP address in the call, but it is 8 bytes shorter, basically the end after the IP address is different. Does anybody have any idea where in the kernel this is handled?

      Concerning 4: dhclient uses a script to set the IP address. NetworkManager adds a parameter to the dhclient call that sets this script to a different script that simply sends all obtained values to NetworkManager using dbus. The original script of dhclient uses ip to set all values which explains why this works without NetworkManager but not with NetworkManager.

      By Michael Hamann on 2018-05-21T10:09:09

      Edited by Ghost User
    • Administrator
      Administrator @root · Imported
      Author Owner

      Created by: ollieparanoid

      Great research!

      I found the definition of NLM_F_REQUEST and all other flags in include/uapi/linux/netlink.h.

      Also I've noted that the flags are slightly different in both versions:

      flags=NLM_F_REQUEST|NLM_F_ACK|0x500 (dhcpcd)
flags=NLM_F_REQUEST|NLM_F_ACK|0x600 (ip)

      The 0x500 seems to consist of:

      NLM_F_CREATE	0x400	/* Create, if it does not exist	*/
NLM_F_CAPPED	0x100	/* request was capped */

      and the 0x600:

      NLM_F_CREATE	0x400	/* Create, if it does not exist	*/
NLM_F_ACK_TLVS	0x200	/* extended ACK TVLs were included */

      ...which makes sense, because the message from ip is longer.

      You have probably already found the manpage of sendmsg(): https://linux.die.net/man/2/sendmsg

      However, I could not find where dhcpcd sets the NLM_F_CAPPED flag. But I hope this is useful already.

      By * postmarketOS Bot on 2018-05-24T20:24:37

    • Administrator moved from pmbootstrap#1461 (closed) · Imported

      moved from pmbootstrap#1461 (closed)

      By Bart Ribbers on 2018-09-17T21:54:10

    • Administrator mentioned in issue #148 (closed) · Imported

      mentioned in issue #148 (closed)

      By JuniorJPDJ on 2018-12-04T13:05:23

    • Administrator
      Administrator @root · Imported
      Author Owner

      @michitux: did your backport of the getrandom syscall (!69 (merged)) fix this by chance, or did you find out anything else? (@JuniorJPDJ is also running into this)

      @JuniorJPDJ: we were looking into the NetworkManager source code, and the source of dhclient, which was working when called manually on the command line. Maybe you can join the effort and play around with that a bit, or read up on some source code.

      See also: the logs posted in #148 (closed).

      By Oliver Smith on 2018-12-05T06:48:25

      Edited by Administrator
    • Administrator changed title from [n5110] dhcpcd not working to [samsung-n5110][samsung-jflte] dhcpcd not working · Imported

      changed title from [n5110] dhcpcd not working to [samsung-n5110][samsung-jflte] dhcpcd not working

      By Oliver Smith on 2018-12-05T06:49:15

    • Administrator
      Administrator @root · Imported
      Author Owner

      No, the backport of getrandom did not fix this. From all I understood so far, this is not about a missing syscall but about some parameters in the netlink protocol that are not understood by the old kernel. To get something usable it might be enough to patch the kernel to ignore them but I have not had a close enough look to see where and if this is possible. To be honest my motivation for this is rather low as the workaround (running dhclient after the connection is established) works and is not too much hassle and I would rather avoid putting more work into this old kernel.

      By Michael Hamann on 2018-12-05T09:09:46

    • Administrator
      Administrator @root · Imported
      Author Owner

      I've found something like this:

      https://wiki.bananeatomic.fr/wiki/ODROID-U3#ipv4_addaddr:_if_addaddress:_Invalid_argument

      Haven't tried

      They suggest to install older dhcpcd - 6.11.5

      By JuniorJPDJ on 2018-12-05T23:29:23

    • Administrator
      Administrator @root · Imported
      Author Owner

      Yes, that version works. http://dl-3.alpinelinux.org/alpine/v3.7/main/armhf/dhcpcd-6.11.5-r1.apk

      I'll later see what change in dhcpcd breaks it. When I installed that version NetworkManager also works.

      By JuniorJPDJ on 2018-12-07T13:51:57

      Edited by Administrator
    • Administrator
      Administrator @root · Imported
      Author Owner

      I'm experiencing the same problems on amazon-tate, and luckily udhcpc works fine where dhcpcd and internal don't.

      NetworkManager should support it, it just needs to be enabled.

      By Gianguido Sorà on 2019-01-17T19:51:47

    • Administrator
      Administrator @root · Imported
      Author Owner

      @gsora: great find! Do you want to make a PR to Alpine's aports, that enables the option (and bumps the pkgrel)?

      By Oliver Smith on 2019-01-18T06:54:21

    • Administrator
      Administrator @root · Imported
      Author Owner

      I would love to, but right now I'm having some bad issues compiling a fork of Alpine's networkmanager package...

      As soon as I get a build working, I'll submit a patch to Alpine's aports (hoping they'll accept the change!).

      By Gianguido Sorà on 2019-01-18T11:40:05

    • Administrator
      Administrator @root · Imported
      Author Owner

      Are you sure the patch you mentioned has ever been merged in networkmanager? Also, the https://mail.gnome.org/archives/networkmanager-list/2014-March/msg00057.html seems to suggest that the patch is not even working for its author.

      By Michael Hamann on 2019-01-18T14:21:22

    • Loading
    • Loading
    • Loading
    • Loading
    • Loading
    • Loading
    • Loading
    • Loading
    • Loading
    • Loading
    Please register or sign in to reply