Question on bb_info_msg, printf, and bb_error_msg?

Sat Jul 9 15:33:44 UTC 2016

Thanks for the reply. I did look at the changes for the 1.25.0, and didn't 
originaly see anything that would effect how I use busybox. Didn't know that 
output was using bb_info_msg, so the lines saying just changing to 
bb_error_msg, or elimanating bb_info_msg didn't stand out.  I then did 
discover the the output was going to stderr instead of stdout. In the change 
log, some say that bb_info_msg was change to bb_info_msg, while others 
are changed to printf?? So, using the 2>&1 isn't a big deal. Changing the 
case and output numbers isn't a big issue either, but having to figure out the 
changes. Been working on g4l project as maintainer since 2004, so gone thru 
lots of versions of busybox with no issues that  I can recall before this. 

The original script has the user select nic, and then manually prompted for 
IP, so added the option to get IP via dhcp or manual. Had a user that had 
system with multiple nics as I had one as well. With my system, windows and 
linux for some reason flipped how they came up, so it was always trying to 
activate the wrong nic since it was the first one. The user wrote this script 
that would check each nic in a system looking to find one that had an active 
link, and also got an IP via dhcp. I have made a few little tweaks, and just 
added an option to display the IP. With the 1.25.0, I did get the error screen 
that it wasn't able to find a link since the output was all blank since it was no 
going to stderr?

ftp://fedora9gcc.dyndns.org/ifcheck2.sh

That script has a few option with udcpc, but the basic output provides the IP 
address a single item. The 3rd line also has it, but has the extra ... at end.

udhcpc

udhcpc (v1.24.2) started
Sending discover...
Sending select for 192.168.128.101...
Lease of 192.168.128.101 obtained, lease time 43200

The information also appears in output ifconfig, but it then has the addr: at 
the beginning of field.

ifconfig

eth0      Link encap:Ethernet  HWaddr 08:00:27:D2:89:C8  
          inet addr:192.168.128.101  Bcast:255.255.255.255  
Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:9 errors:0 dropped:0 overruns:0 frame:0
          TX packets:10 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:2796 (2.7 KiB)  TX bytes:2856 (2.7 KiB)

The script run by the udhcpc does have a $ip variable in one place, and I 
tried putting an export after that line, but new got anything in environment. 
The only reference I could really see is if one was using the option to request 
a specific IP from the dhcpd server? 

Did a google seach and most of what I could find was dating back to early 
2000s  version that was standalone, and then info on how it was dropped 
after being incorporated into busybox. 

Even ran the command with an strace to see if I could see something, but IP 
only seems to be on the lines that are being send to stdout in the 1.24.2 
version. 

So, it there is a way of getting if from the script, I haven't found it yet, so 
simple solution may just be to use the 2>&1, change Lease to lease, and -f3 
to -f4. 

Learned a lot of things from this list and others, but some of it is beyond my 
needs or the time I have. Thanks for taking the time.

On 9 Jul 2016 at 13:22, Xabier Oneca  --  xOneca wrote:

From:           	Xabier Oneca  --  xOneca <xoneca at gmail.com>
Date sent:      	Sat, 9 Jul 2016 13:22:27 +0200
Subject:        	Re: Question on bb_info_msg, printf, and bb_error_msg?
To:             	"Michael D. Setzer II" <mikes at kuentos.guam.net>
Copies to:      	Denys Vlasenko <vda.linux at googlemail.com>, busybox 
<busybox at busybox.net>

> Hello Michael,
> 
> > First, Thanks for the reply. I still not clear why in the changes list it shows that
> > sometimes bb_info_msg is changed to printf and sometimes changed to
> > bb_error_msg. Actually, did a test and modified the dhcpc.c to change the
> > bb_error_msg to printf to see if it would work the same. Did find that I also
> > had to add \n or output was on same line, but it did get the output to go to
> > stdout instead of stderr, and  had the output without the added field. The
> > case issue would still be there, but that is an easy fix. It is not the
> > inconvience, but the consistance, and it may be there is good reason that I
> > am not aware of?
> 
> As I see it, this was not changed with output consistency in mind, but
> to send what really is logging output to stderr (and, at the same
> time, cut in binary size a few bytes). That udhcpc output was logging,
> so it was wrong to output it to stdout.
> 
> You can argue with Denys about this change, but really the right way
> (and actually *easiest* one, IMO) to get information from udhcpc is
> using the callback script.
> 
> > Second, I was not aware that the udhcpc.sh was a script to be modified?? I
> > do see the variable $ip, but it is only one renew section, and doesn't seem to
> > show where it gets defined. Is there somewhere that this process is defined?
> > A user had submitted the script that would process systems with multiple nics
> > to find the active nics, and which one actually got an IP address. Since it
> > worked fine I didn't go farther. I've got a couple systems with 2 nics, and have
> > one system that has 9 ethernet ports with one single nic, and two 4 port nics,
> > and it works fine with that.
> 
> Yes, the callback script can be customized, although it usually
> doesn't have to. That script is called with some information extracted
> from the packet and set as environment variables using fill_envp() (in
> https://git.busybox.net/busybox/tree/networking/udhcp/dhcpc.c#n418).
> You can find there the ones you need.
> 
> I'm not an expert in DHCP, so I can't help you with which information
> is available in each stage in with the callback is used.
> 
> Hope that helps,
> 
> Xabier Oneca_,,_

+----------------------------------------------------------+
  Michael D. Setzer II -  Computer Science Instructor      
  Guam Community College  Computer Center                  
  mailto:mikes at kuentos.guam.net                            
  mailto:msetzerii at gmail.com
  Guam - Where America's Day Begins                        
  G4L Disk Imaging Project maintainer 
  http://sourceforge.net/projects/g4l/
+----------------------------------------------------------+

http://setiathome.berkeley.edu (Original)
Number of Seti Units Returned:  19,471
Processing time:  32 years, 290 days, 12 hours, 58 minutes
(Total Hours: 287,489)

BOINC at HOME CREDITS
ABC         16613838.513356   |   EINSTEIN    
104177525.45569545901075.143631
ROSETTA     45901075.143631   |   SETI        86335992.000885