dhcpcd-discuss

Thanks. Glad to hear from you.

I upgraded to version 6.11.5 as per your advice and the problem vanished!

As requested I have pasted below the backtrace for the previous version I
was using.

-------------------------------------------------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------------------------------------------------
# dhcpcd --version
dhcpcd 6.11.1
Copyright (c) 2006-2016 Roy Marples

# gdb dhcpcd
GNU gdb (GDB) 7.10.1
...
Reading symbols from dhcpcd...done.

(gdb) run
Starting program: /sbin/dhcpcd
control_open: Connection refused
eth0: soliciting a DHCP lease
eth0: probing for an IPv4LL address

Program received signal SIGSEGV, Segmentation fault.
ipv4ll_conflicted (astate=0x66700, amsg=0xbe9a2a44) at ipv4ll.c:257
257    ipv4ll.c: No such file or directory.

(gdb) backtrace
#0  ipv4ll_conflicted (astate=0x66700, amsg=0xbe9a2a44) at ipv4ll.c:257
#1  0x000223dc in arp_packet (arg=<optimized out>) at arp.c:192
#2  0x000171c4 in eloop_start (eloop=0x65be0, signals=0xbe9a2bb8,
    signals@entry=0xbe9a2bb0) at eloop.c:950
#3  0x00012d50 in main (argc=1, argv=<optimized out>) at dhcpcd.c:1926

(gdb) backtrace full
#0  ipv4ll_conflicted (astate=0x66700, amsg=0xbe9a2a44) at ipv4ll.c:257
        ifp = 0x66608
        state = 0x66388
        fail = 0
        __func__ = "ipv4ll_conflicted"
#1  0x000223dc in arp_packet (arg=<optimized out>) at arp.c:192
        ifp = <optimized out>
        ifn = 0x0
        buf =
"\000\001\b\000\006\004\000\001T\356uQ\001\347\nZL{\000\000\000\000\000\000\nZL\001",
'\000' <repeats 18 times>, "M\025\270+\232\276\340[\006"
        ar = <optimized out>
        arm = {op = 41019,
          sha =
"T\356uQ\001\347\000\000\000\000\251\376q1_\275\356\266\064\325", sip =
{s_addr = 2068601354},
          tha =
"\000\000\000\000\000\000\000\000\061\000\000\000\000g\006\000\bf\006", tip
= {s_addr = 21781002}}
        bytes = <optimized out>
        state = 0x666f0
        astate = <optimized out>
        astaten = 0x0
        hw_s = 0xbe9a2a80 "T\356uQ\001\347\nZL{"
        hw_t = 0xbe9a2a8a ""
        flags = 0
---Type <return> to continue, or q <return> to quit---
#2  0x000171c4 in eloop_start (eloop=0x65be0, signals=0xbe9a2bb8,
    signals@entry=0xbe9a2bb0) at eloop.c:950
        n = <optimized out>
        e = <optimized out>
        t = 0x66368
        now = {tv_sec = 83, tv_nsec = 243208104}
        ts = <optimized out>
        tsp = <optimized out>
        t0 = <optimized out>
        epe = {events = 1, data = {ptr = 0x66730, fd = 419632, u32 =
419632,
            u64 = 419632}}
        timeout = <optimized out>
#3  0x00012d50 in main (argc=1, argv=<optimized out>) at dhcpcd.c:1926
        ctx = {pidfile = "/var/run/dhcpcd.pid", '\000' <repeats 23 times>,
          cffile = 0x3af57 "/etc/dhcpcd.conf", options =
309095022435652617,
          logfile = 0x0, log_fd = -1, argc = 1, argv = 0xbe9a2e44, ifac =
0,
          ifav = 0x0, ifdc = 0, ifdv = 0x0, ifc = 0, ifv = 0xbe9a2e48,
          ifcc = 0, ifcv = 0x0, duid = 0x0, duid_len = 0, ifaces = 0x661c8,
          pf_inet_fd = 6, priv = 0x65c38, link_fd = 4, seq = 3, sseq = 3,
          sigset = {__val = {0 <repeats 32 times>}}, eloop = 0x65be0,
          control_fd = 8, control_unpriv_fd = 9, control_fds = {
            tqh_first = 0x0, tqh_last = 0xbe9a2c44},
          control_sock = "/var/run/dhcpcd.sock", '\000' <repeats 20 times>,
---Type <return> to continue, or q <return> to quit---
          control_group = 0, vivso = 0x0, vivso_len = 0,
          randomstate = 0xb6f361a4 "\003", ppid = 0, pseq = 0,
          dhcp_opts = 0x645a8, dhcp_opts_len = 123, ipv4_routes = 0x66448,
          ipv4_kroutes = 0x66458, udp_fd = 10, opt_buffer = 0x0,
          opt_buffer_len = 0, secret = 0x0, secret_len = 0, nd_opts =
0x65ad0,
          nd_opts_len = 6, dhcp6_opts = 0x69a70, dhcp6_opts_len = 70,
          ipv6 = 0x0}
        ifo = 0x0
        ifp = 0x0
        family = <optimized out>
        opt = <optimized out>
        oi = 0
        i = <optimized out>
        t = <optimized out>
        len = <optimized out>
        pid = <optimized out>
        sig = <optimized out>
        siga = <optimized out>
        __func__ = "main"
-------------------------------------------------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------------------------------------------------

> Reverse ARP Proxy (or anything similar) only needs to be running on one
> device on the same network segment to trigger a false positive for
> IPv4LL, does not have to be the same host.

As far as this comment is concerned I was only having one host and one
device running dhcpcd in the network.
So I am not aware of any other RARP proxy running in the network.

Thank you very much for the help.

Thanks and regards,
Shreesha

On Thu, Dec 29, 2016 at 7:43 PM, Roy Marples <roy@xxxxxxxxxxxx> wrote:

> Hi
>
> On 26/12/16 05:24, shreesha vitthala wrote:
> > Hello,
> >
> > I have a device running dhcpcd. When I remove the router connection it
> > acquires a 169.x.x.x address automatically. But this works mostly when I
> > disconnect my PC running Ubuntu 16.04 LTS from the network. I'm using
> > this PC to develop and deploy firmware to the device.
> > When the PC is connected dhcpcd mostly fails after this line -
> >
> >           eth0: probing for an IPv4LL address
> >
> > and ends up in segmentation fault.
>
> You also failed to say which dhcpcd version you're running.
> Can you upgrade to dhcpcd-6.11.5 please?
>
> Can you post a backtrace please?
>
> > However when I use avahi the eth0:avahi adapter successfully acquires
> > 169.x.x.x address even when my PC is connected.
> >
> > From the man page I could get below information but it is not sufficent
> > for me to pin-point the cause for the failure -
> > "
> >
> > When using IPv4LL, *dhcpcd* nearly always succeeds and returns an exit
> code
> >      of 0.  In the rare case it fails, it normally means that there is a
> >      reverse ARP proxy installed which always defeats IPv4LL probing.
> > "
> >
> > I found that my PC has RARP installed but it is not running in my
> > process list.
> > The command I used to find this is "ps -ef|grep rarp"
> >
> > Can you please enlighen me on possible causes for this?
>
> Reverse ARP Proxy (or anything similar) only needs to be running on one
> device on the same network segment to trigger a false positive for
> IPv4LL, does not have to be the same host.
>
> Roy
>