dhcpcd-discuss

On 20/08/2019 14:29, Yegor Yefremov wrote:
> Even with same card I get different leases. If I understand the whole
> QMI stuff correctly then the card itself has a DHCP server inside the
> firmware. And all we need to do is to setup IP configuration for wwan0
> interface. Hence it doesn't matter whether we get the same of a
> different IP as we always have only one client.

OK. dhcpcd cannot know this, so lets strive to be RFC compliant.
We'll use the DUID and interface index, as the client id.

> > > I'm trying to understand what was made in this patch that adds raw-ip
> > > support to the ISC DHCP [1]. Seems like there is no way to avoid
> > > packet header manipulation.
> > >
> > > [1] https://mail.gnome.org/archives/networkmanager-list/2015-December/msg00044.html
> >
> > The attached patch may help dhcpcd get further.
>
> With the patch applied:
>
> # dhcpcd wwan0
> dhcpcd-8.0.2 starting
> [  150.103174] 8021q: 802.1Q VLAN Support v1.8
> [  150.107618] 8021q: adding VLAN 0 to HW filter on device eth0
> [  150.113994] 8021q: adding VLAN 0 to HW filter on device eth1
> wwan0: executing `/lib/dhcpcd/dhcpcd-run-hooks' PREINIT
> wwan0: executing `/lib/dhcpcd/dhcpcd-run-hooks' NOCARRIER
> wwan0: waiting for carrier
> wwan0: carrier acquired
> wwan0: executing `/lib/dhcpcd/dhcpcd-run-hooks' CARRIER
> DUID 00:01:00:01:c7:92:bc:92:74:6a:8f:ff:50:55
> wwan0: IAID 00:00:00:06
> wwan0: delaying IPv6 router solicitation for 0.6 seconds
> wwan0: delaying IPv4 for 0.9 seconds
> wwan0: soliciting an IPv6 router
> wwan0: delaying Router Solicitation for LL address
> wwan0: soliciting a DHCP lease
> wwan0: sending DISCOVER (xid 0x53b45005), next in 4.6 seconds
> dhcp_openbpf: wwan0: Invalid argument
> wwan0: sending DISCOVER (xid 0x53b45005), next in 8.8 seconds
> dhcp_openbpf: wwan0: Invalid argument
> wwan0: sending DISCOVER (xid 0x53b45005), next in 16.2 seconds
> dhcp_openbpf: wwan0: Invalid argument

eek, that's not good.
Linux is a special snowflake with opening BPF sockets and I don't have a 
VM handy right now. However, this untested patch should hopefully give 
more info as to where the error is.

Roy

diff --git a/src/if-linux.c b/src/if-linux.c
index b7e84eb5..d033a58e 100644
--- a/src/if-linux.c
+++ b/src/if-linux.c
@@ -1357,6 +1357,7 @@ bpf_open(struct interface *ifp, int (*filter)(struct interface *, int))
 	int n;
 #endif
 
+	logerrx("OPEN BPF SOCKET");
 #define SF	SOCK_CLOEXEC | SOCK_NONBLOCK
 	if ((s = xsocket(PF_PACKET, SOCK_RAW | SF, htons(ETH_P_ALL))) == -1)
 		return -1;
@@ -1376,10 +1377,12 @@ bpf_open(struct interface *ifp, int (*filter)(struct interface *, int))
 		state->buffer_len = state->buffer_pos = 0;
 	}
 
+	logerrx("APPLYING FILTER");
 	if (filter(ifp, s) != 0)
 		goto eexit;
 
 #ifdef PACKET_AUXDATA
+	logerrx("TOGGLING PACKET_AUXDATA");
 	n = 1;
 	if (setsockopt(s, SOL_PACKET, PACKET_AUXDATA, &n, sizeof(n)) != 0) {
 		if (errno != ENOPROTOOPT)
@@ -1391,6 +1394,7 @@ bpf_open(struct interface *ifp, int (*filter)(struct interface *, int))
 	su.sll.sll_family = PF_PACKET;
 	su.sll.sll_protocol = htons(ETH_P_ALL);
 	su.sll.sll_ifindex = (int)ifp->index;
+	logerrx("BINDING SOCKET");
 	if (bind(s, &su.sa, sizeof(su.sll)) == -1)
 		goto eexit;
 	return s;