[FS#4242] errors about udhcpc v1.34.1

[OpenWrt Bugs]

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.

The following task has been changed.  The changes are listed below.  For full information about what has changed, visit the URL and click the History tab.

FS#4242 - errors about udhcpc v1.34.1 
User who did this: Yousong Zhou (yousong)
Task details edited:
-------
udhcpc in busybox v1.34.1
I need to start two udhcpc with different interface, eth0, eth0.700
Some times I found the ip show is same:


eth0      Link encap:Ethernet  HWaddr 00:11:22:33:44:90
          inet addr:192.168.2.11  Bcast:192.168.2.255  Mask:255.255.255.0
          inet6 addr: fe80::211:22ff:fe33:4490/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:29617 errors:0 dropped:0 overruns:0 frame:0
          TX packets:29546 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:2795324 (2.6 MiB)  TX bytes:2756288 (2.6 MiB)
          Interrupt:45
eth0.700  Link encap:Ethernet  HWaddr 00:11:22:33:44:90
          inet addr:192.168.2.11  Bcast:192.168.2.255  Mask:255.255.255.0
          inet6 addr: fe80::211:22ff:fe33:4490/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1493 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2865 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:105529 (103.0 KiB)  TX bytes:235432 (229.9 KiB)


in fact they should not use same ip, 
because the server is configured as 192.169.3.1 for eth0,with range:192.168.3.20,192.168.3.30 for eth0
and another interface server configured as 192.168.2.1 with range:192.168.2.10-192.168.2.30  for eth0.700

from the log, it shows:


2022-01-27T07:05:11.38086 udhcpc: started, v1.34.1
2022-01-27T07:05:11.38087 udhcpc: started, v1.34.1
2022-01-27T07:05:11.49480 udhcpc: broadcasting discover
2022-01-27T07:05:11.50489 udhcpc: broadcasting discover
2022-01-27T07:05:14.58804 udhcpc: broadcasting discover
2022-01-27T07:05:14.58807 udhcpc: broadcasting discover
====2022-01-27T07:05:14.68504 udhcpc: broadcasting select for 192.168.2.11, server 192.168.2.1
2022-01-27T07:05:14.68507 udhcpc: broadcasting select for 192.168.3.21, server 192.168.3.1
2022-01-27T07:05:14.82465 udhcpc: lease of 192.168.2.11 obtained from 192.168.2.1, lease time 588
2022-01-27T07:05:14.82505 udhcpc: lease of 192.168.2.11 obtained from 192.168.3.1, lease time 588====
2022-01-27T07:05:14.83214 udhcpc: ip addr add 192.168.2.11/255.255.255.0 broadcast + dev eth0.700
2022-01-27T07:05:14.83229 udhcpc: ip addr add 192.168.2.11/255.255.255.0 broadcast + dev eth0
2022-01-27T07:10:08.68581 udhcpc: sending renew to server 192.168.3.1
2022-01-27T07:10:08.90760 udhcpc: sending renew to server 192.168.2.1
2022-01-27T07:10:08.96883 udhcpc: lease of 192.168.2.11 obtained from 192.168.2.1, lease time 600
2022-01-27T07:10:08.97304 udhcpc: ip addr add 192.168.2.11/255.255.255.0 broadcast + dev eth0.700


it can prove the server allocate a right address for each interface, but I don't know why it bind the same address as eth0.700
==========seems like has memory cover issue in udhcpc.==========
==========The issue occurred in a very few probability.========== 

The start command is :


/sbin/udhcpc -A 0 -f -S -x 0x7d:00000de9270106443845464344020c50454d323031303034343930030f354752656365697665722d48472d31 -V ,01.00.00.2180,,460008944136270,898600910920f9073973,oam 10.48.35.88,oam 2409:891f:9306:45f0:211:22ff:fe33:4492,payload 10.96.166.115,payload 2409:891e:9326:b7b5:0211:22ff:fe33:4493 -x hostname:5GFMR21 -i eth0
/sbin/udhcpc -A 0 -f -S -x 0x7d:00000de9270106443845464344020c50454d323031303034343930030f354752656365697665722d48472d31 -V ,01.00.00.2180,,460008944136270,898600910920f9073973,oam 10.48.35.88,oam 2409:891f:9306:45f0:211:22ff:fe33:4492,payload 10.96.166.115,payload 2409:891e:9326:b7b5:0211:22ff:fe33:4493 -x hostname:5GFMR21 -i eth0.700

-------

More information can be found at the following URL:
https://bugs.openwrt.org/index.php?do=details&task_id=4242

You are receiving this message because you have requested it from the Flyspray bugtracking system.  If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.