Re: udhcpc: IPv4LL (unique link local address when DHCP server does not respond)

[Denys Vlasenko]

busybox has a zcip applet for this
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

sed -f -

[Jack Bates]

I wish that the following worked, but it doesn't:


nottheoilrig@debian:~/busybox-1.24.2$ echo s/foo/bar/ | ./busybox sed -f -
sed: can't open '-': No such file or directory
1 nottheoilrig@debian:~/busybox-1.24.2$


Is this by design? Would you welcome a patch to make it work?

I sometimes use "echo -e '... \n ...' | sed -f - -i filename" in e.g. 
Debian preseed files or Makefiles, because the sed a, i and c commands 
are particular about newline characters.

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: /etc/network/interfaces declarations

[David Henderson]

Awesome, thanks for the additional info Isaac!  I'll begin playing
around with things and see if I can get it going!

Dave


On 4/4/16, Isaac Dunham  wrote:
> Replying to this email and your other email.
>
> Clarifying plugins:
> ifup runs *all* scripts in /etc/network/if-*.d, with the time depending
> on the directory.
> Plugins are simply scripts dropped into the right directories, that use
> the environment variables set by ifup.
> As a result, the line
>   dns-nameservers 8.8.8.8 4.4.4.4
>
> would result in every script in /etc/network/if-*.d/ getting the variable:
> IF_DNS_NAMESERVERS="8.8.8.8 4.4.4.4"
>
> So it doesn't matter what the name of the script is. (It could be
> 'nameservers', 'resolvconf', or even 'foobar'.)
>
> On a computer with a working /etc/network/interfaces configuration, you
> can switch to busybox ifup and it should continue working.
>
> On a system with just busybox ifup/ifdown, you would need to install
> resolvconf and wpa_supplicant, making sure that there are scripts in
> /etc/network/if-*.d/.
>
> On Mon, Apr 04, 2016 at 04:03:55PM -0400, David Henderson wrote:
>> >> And I just wanted to make sure that I could use something like:
>> >>
>> >> ifup -i /etc/network/interfaces eth0
>> >>
>> >> will process that file as is defined (like the example provided
>> >> below).  There isn't anythink like this with just ifconfig correct?
>> > No, ifconfig doesn't do all that.
>> >
>> >
>> > The 'example provided' is only a list of options.
>> >
>> > If I'm understanding correctly, you're probably thinking of something
>> > more like this:
>> > ===
>> > # eth0 here is manually configured ethernet, brought up by hand
>> > iface eth0 inet static
>> >address 192.168.0.10
>> >netmask 255.255.255.0
>> >gateway 192.168.0.1
>> >dns-nameservers 1.1.1.1 1.1.1.2 1.1.1.3
>> >dns-search newdomain.local olddomain.local outside.com
>> >
>> > # wlan0 is wireless auto-configured by dhcp, brought up automatically
>> > auto wlan0
>> > iface wlan0 inet dhcp
>> >wpa-conf /etc/wpa_supplicant.conf
>> > ===
>>
>> Yeah, sorry about that, but you are correct in your assumption.
>>
>>
>> > Assuming you have resolvconf and wpa-supplicant installed, it should
>> > work.
>> > But unless you use wireless in a stationary PC, you would do better to
>> > use 'wpa-roam':
>> > ===
>> > # 'default' should not be marked 'auto'; IT IS MAGIC!! ;)
>> > # the wpa_supplicant plugin will bring up the logical interface
>> > specified
>> > # by 'id_str' in wpa_supplicant.conf, or 'default' if id_str is not
>> > # configured.
>> > # The physical interface you run wpa_supplicant on will be used for
>> > # any logical interfaces.
>> >
>> > iface default inet dhcp
>> >
>> > auto wlan0
>> > iface wlan0 inet manual
>> >wpa-roam /etc/wpa_supplicant.conf
>> > ===
>> >
>> > "-i CONFIGFILE" is optional; it defaults to /etc/network/interfaces.
>>
>> What's the advantage to using 'wpa-roam' vs 'wpa-conf'?
>
> 'wpa-conf' will run wpa_supplicant, then assume that there's a connection
> and continue, starting the DHCP client or running the manual config.
>
> 'wpa-roam' will run wpa_supplicant, listen until wpa_supplicant reports a
> connection, and then apply the appropriate configuration for the network.
>
> As a result, wpa-conf has a tendency to cause hangs in the boot process,
> while wpa-roam yields faster starts and works better with switching
> networks.
> (In some cases, buggy out-of-tree drivers can panic the kernel with
> wpa-conf; several years ago I noticed that madwifi liked to panic if the
> dhcp client started before the connection was complete.)
>
> HTH,
> Isaac Dunham
>
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: udhcpc: IPv4LL (unique link local address when DHCP server does not respond)

[Peter Faasse]

On Tuesday 05 April 2016 12:22:06 Prasant J wrote:
> Hi,
> 
> I'm using busybox version 1.23.1 (yocto jethro release).
> 
> When DHCP server is not available I see my linux system getting IPv4LL
> (Link local) address (169.254). We may have many linux sytsems
> running together.
> 
> 
> My queries:
> - Who assigns a link local address to the system? (ifup/udhcpc/... any
> other tool)

Not quite sure about busy box-situation.. I've experimented with this link-
local addresses. Usually, dhcpcd assigns them if/when no dhcp server is 
present. dhcpcd has an option (from-memory: -L) to disable this. With -L, if 
no dhcp server is present, no address at all will be assigned.

> - Does udhcpc/ifup ensures each system is assigned a unique link local
> address when multiple systems may be present?

There it gets really interesting. 

A bit of background:

This link-local addressing mechanism is -when used intentionally- usually part 
of a so-called 'bonjour' (Apple-name..), avahi (one of the linux 
implementations), mdns (more generic name) network. Yep: many names for the 
same thing. 'It' is a standard developed by Apple, with free implementations 
on Linux. The goal is to provide no-configuration networking to a cluster of 
computers all connected to a local network. The 169.254.X.X IP range is 'free' 
for this. 

IP address assignment works roughly as follows:

When a node becomes active on such a network, it 'proclaims' its intention to 
use a 'wisely' choosen IP address by sending network packets to the 
169.254.X.X network. If another node on the network already 'owns' that 
address, and receives such proclamation packets, the already-owner responds, 
effectively complaining that the newcomer is attempting to steal its address. 
The newcomer must respond with a re-try of proclamation with a different 
address. This is not race-free/bomb-proof, so the mechanism does allow a node 
to run-time re-assign its own address. NB: the 'wisely' in previous section 
usually entails that a node becoming active attempts to re-use the address 
that 'worked' the last time.. NB2: Yes a run-time re-assignment is a desaster 
for already-established TCP sockets, but: so is a network with an ghost of 
your IP address :-)

The mdns protocol 'stuff' provides a whole load of other nice facilities. How 
much of that is active depends on how much of the zeroconf 'stack' you have 
installed and -hem, hem- configured... :-)  A fully active stack would allow a 
cluster of zeroconf computers to form a network of peers with no dedicated 
'servers' that can assing IP addresses, resolve names and find and access 
services (think: printer, ftp/nfs server, www-server) on the nodes of the 
cluster.

That dhcpcd (or brother/sister app..) supports assigning a zeroconf address is 
the first step of a long and -for me at least- interesting road. I hardly ever 
*use* this mechanism on Linux, but it was a nice thing to study/learn about... 

NB: there is an O'Reilly book about 'zeroconf networking'.. 

> 
> 
> Any inputs will be of help to me.
> 
> Regards, Pj
> ___
> busybox mailing list
> busybox@busybox.net
> http://lists.busybox.net/mailman/listinfo/busybox

signature.asc
Description: This is a digitally signed message part.
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Busybox binary ends up only 340 bytes

[Lauri Kasanen]

On Mon, Apr 4, 2016, at 23:52, st...@weaverpad.com wrote:
> I am trying to build Busybox for my ARMv7-M microprocessor based
> board. It seems to compile everything as configured; however, the
> resulting binary is only 340 bytes in size. The map file shows all
> files that were built, but there is no space allocated for them. It's
> as if it has decided to discard all sections as unused. I've tried for
> a while now to figure out why it might be doing this. I am using
> Buildroot to automate the entire process. Can anyone provide any
> guidance on how to go about fixing this? What other information should
> I provide?

I hit similar on m68k a while back - the platform's link scripts were
not prepared for gc-sections, and so everything got pruned. Since
editing your platform may not be an option for you, the easiest
workaround is to remove gc-sections from scripts/trylink. Specifically,
look for the logic that checks for it, and empties the variable - make
it always empty.

- Lauri

-- 
http://www.fastmail.com - Or how I learned to stop worrying and
  love email again

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

udhcpc: IPv4LL (unique link local address when DHCP server does not respond)

[Prasant J]

Hi,

I'm using busybox version 1.23.1 (yocto jethro release).

When DHCP server is not available I see my linux system getting IPv4LL
(Link local) address (169.254). We may have many linux sytsems
running together.


My queries:
- Who assigns a link local address to the system? (ifup/udhcpc/... any
other tool)
- Does udhcpc/ifup ensures each system is assigned a unique link local
address when multiple systems may be present?


Any inputs will be of help to me.

Regards, Pj
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox