dhcpcd-discuss

Hi

On 24/05/2014 16:10, Peter Mattern wrote:
> Thank You very much for Your quick response and sorry for my delayed
> one. Will try to be faster next time.
>
> So I applied the patch You provided against dhcp6.c, recompiled dhcpcd
> and took a look at systemd's journal. As main difference there were
> four additional lines
>      d6_open 0
>      d6_open 1
>      d6_open 2
>      d6_open 3
> at the end, a more verbose sdiff is attached. Also attached the log
> from an i686 laptop where the connection works flawlessly as mentioned
> in my first post.

Ah, we need to change the patch a little so that the output appears 
inline rather than at the end.
It's useless as it is! Change each added printf line to look like this

fprintf(stderr, "0\n");

But ensure each number is different.
New output should show more detail.

> There's one more thing imo worth mentioning: if CPPFLAGS comprises
> -D_FORTIFY_SOURCE=2, which is e. g. default in Arch Linux's ABS, there
> are three warnings
>           dhcp.c: In function 'dhcp_handleifudp':
>           dhcp.c:2637:2: warning: ignoring return value of 'read',
> declared with attribute warn_unused_result [-Wunused-result]
>             (void)read(state->udp_fd, buffer, sizeof(buffer));
>             ^
>
>           dhcp.c: In function 'dhcp_handleudp':
>           dhcp.c:2622:2: warning: ignoring return value of 'read',
> declared with attribute warn_unused_result [-Wunused-result]
>             (void)read(ctx->udp_fd, buffer, sizeof(buffer));

Already fixed.

>             ^
>
>           compat/arc4random.c: In function 'arc4_stir':
>           compat/arc4random.c:112:3: warning: ignoring return value of
> 'read', declared with attribute warn_unused_result [-Wunused-result]
>              (void)read(fd, rdat.rnd, sizeof(rdat.rnd));

Don't care about fixing that because if we did read something it's a 
good random seed, otherwise just use what we have on the unassigned 
stack.
The (void) marking is there to show we really don't care if the read 
worked or not.
Besides, this function should really be included in glibc someday.

Thanks

Roy