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 <[email protected]> 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" <[email protected]> Copies to: Denys Vlasenko <[email protected]>, busybox <[email protected]> > 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:[email protected] mailto:[email protected] 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@HOME CREDITS ABC 16613838.513356 | EINSTEIN 104177525.45569545901075.143631 ROSETTA 45901075.143631 | SETI 86335992.000885 _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
