ifconfig refactoring for FreeBSD

Dan writes "Based on Sam Leffer's suggestion, Bruce Simpson has been working on refactoring ifconfig(8). ifconfig is a FreeBSD unix utility used to assign an address to a network interface and/or configure network interface parameters. Bruce says that ifconfig has grown increasingly large and become unwieldy. Part of the effort has been to get a handle on all of the options that are currently supported so he has written a YACC grammar for it. He has uploaded some grammer, created a design document and also generated a PDF file you can view which shows you syntax diagrams for each part of the parse tree."

Comments

Wondering what YACC is?

[a.koepke]

For those of you who do not know what YACC is all about

Its good to see something like this happening as ifconfig is not only used on FreeBSD but also on most (all?) Linux distros.

Ifconfig is just one of the many contributions the BSD projects have given to the Linux and UNIX community.

PS: To all those "bsd is dying" trolls, things like this show its not. Without the work of the BSD projects you wouldn't have some of the many tools you use each day.

Re:Wondering what YACC is?

[__past__]

Its good to see something like this happening as ifconfig is not only used on FreeBSD but also on most (all?) Linux distros.

They all have an ifconfig (even windows has, but it's spelled ipconfig), but a different one. The GNU version takes different arguments anyway - like for example none at all, which the FreeBSD version doesn't allow - so this will most likely not affect any Linux user in any way.

To all those "bsd is dying" trolls, things like this show its not. Without the work of the BSD projects you wouldn't have some of the many tools you use each day.

If the only sign of life of the BSDs would be a refactoring of one little command-line utility that has been around for decades, I think calling it "dead" would be a good approximation. Fortunatly it isn't. There are enough more interesting things going on the BSD world.

In other words, this is really one of the most boring stories ever, even considering the "let's duplicate the daemonnews slashbox" policy /. recently adopted.

Re:Wondering what YACC is?

[ctr2sprt]

In other words, this is really one of the most boring stories ever, even considering the "let's duplicate the daemonnews slashbox" policy /. recently adopted.

I think the issue here is that most Slashdot editors don't know or care about the BSDs, but they need to post some articles. Since they have no way of distinguishing between interesting news and uninteresting, they rely on other sites to assign importance. The effects of this are obvious: not a lot of replies, over half of them trolls, and people getting their BSD news elsewhere.

You heard it here first: The Slashdot BSD Section is Dying.

Re:Wondering what YACC is?

[Pathwalker]

You might want to consider swapping out rl0 for a better card - read /usr/src/sys/pci/if_rl.c for details.

The RealTek 8139 PCI NIC redefines the meaning of 'low end.' This is
probably the worst PCI ethernet controller ever made, with the possible
exception of the FEAST chip made by SMC. The 8139 supports bus-master
DMA, but it has a terrible interface that nullifies any performance
gains that bus-master DMA usually offers.

Re:Wondering what YACC is?

[utlemming]

No, the problem is that when you actually submit an interesting BSD article for /., they ignore it. For example, how many of us BSD users knew that the BSD developers actually commented on the SCO suit?

"Your story just might not be interesting!

This last one requires a little explanation: if you submit a story, and we don't select it because we think it's not particularly interesting, we're not making a judgment about you as a human being. Deciding the interest level of a story is a very subjective thing, and we have to take into account not only the intrinsic interest of the story itself, but what else is happening that day. On a day when lots of things are happening, we reject some very good stories. But on a day when nothing interesting is happening, we may post something not really as cool.

This was taken from the /. FAQ

The conclusion that I have come to is that the /. editors just don't care about BSD. And the editors probably use the above quote to get out of anything us BSD users might find interesting. Mathmatically, it would be represented, "Linux == Interesting; BSD != Linux; BSD != Interesting" and since "BSD != Linux then BSD MUST be dying."

And I think that your absolutely right, about them not knowing what is worthy of reporting and what is not. When I first read the Refacturing of IFCONFIG, the thought that went through my mind was, "Who cares?" It really has no bearing on the useability of the OS. I think the real issue is that /. needs to put some one who actually uses BSD as an OS doing the editing. I think then, we might see some interesting.

Personally I think that the comment about BSD users getting BSD news elsewhere is pretty insightful. The only reason I read /. is because there are other technology issues which I am interested in and the Linux movement does facinate me. But nontheless, with the general bigotted spirit towards the BSD's, I can see why I, and most likely others go elsewhere.

A while back I fired off an email to address the concerns of us BSD users. The reply I got back from CdrTaco was essentially if more BSD users read /., then the trolls would be silenced with more BSD users moderating, and more /. stories would be about BSD, because there would be more submissions.

Well, I'll get off my soap box now, and wait till I get moderated down. Any bets on what it will be? Flamebait? Or maybe Off Topic. But moderators, if I can not be insightful or interesting, please vote for Flamebait.

Re:Wondering what YACC is?

[edhall]

The ifconfig thread is interesting from a number of perspectives. Given that ifconfig is perhaps the command-line utility embodying BSD's decades-old networking legacy, it takes some courage to propose a radical reworking of it. Using a formal grammar rather than the ad hoc accretion of command-line options that 95% of Unix/Linux utilities use is another bold step. And opening the way to added functionality (one of the motivations for this project) adds to the interest. Sure, just looking at the surface it's easy to say "so they're changing some arguments to some crufty old Unix command -- ho hum." But it may well represent the initial step in a complete rethinking of how networking is administered at the host level. Even if it doesn't pan out that way, it's worth taking notice.

BTW, I don't moderate BSD stories any more. When I mod down the trolls, I tend to get slammed in metamod. (Talk about a hostile environment!) Hope springs eternal, though -- I keep thinking that /. will eventually start doing some housekeeping.

-Ed

Re:Wondering what YACC is?

[semanticgap]

The GNU version takes different arguments anyway - like for example none at all, which the FreeBSD version doesn't allow

When was the last time you used FreeBSD?

$ uname
FreeBSD
$ ifconfig
rl0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet 192.168.1.10 netmask 0xffffff00 broadcast 192.168.1.255
[snip]

FreeBSD has the best ifconfig of all Unices I've used. My favorite part is being albe to use the slash notation for the netmask, e.g. to add a secondary IP to fxp0, you can do:

# ifconfig fxp0 192.168.1.12/32 alias

Re:How about live /etc/rc.conf changes?

[zulux]

Hmmm...

Can't you just run /etc/rc.network and it will re-parse rc.conf?

Using ifconfig w/out arguments

[RT Alec]

Starting with FreeBSD 4.x, ifconfig with no arguments simply lists all interfaces the kernel has found, and their configuration details.

%>ifconfig
de0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet 10.0.254.254 netmask 0xffff0000 broadcast 10.0.255.255
ether 00:e0:29:37:09:a8
media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
de1: flags=8c43<UP,BROADCAST,RUNNING,OACTIVE,SIMPLEX,MU LTICAST> mtu 1500
inet 10.1.254.254 netmask 0xffff0000 broadcast 10.1.255.255
ether 00:e0:29:37:09:a9
media: Ethernet autoselect
de2: flags=8c43<UP,BROADCAST,RUNNING,OACTIVE,SIMPLEX,MU LTICAST> mtu 1500
inet 10.2.254.254 netmask 0xffff0000 broadcast 10.2.255.255
ether 00:e0:29:37:0c:d6
media: Ethernet autoselect
de3: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet 10.3.254.254 netmask 0xffff0000 broadcast 10.3.255.255
ether 00:e0:29:37:0c:d7
media: Ethernet autoselect (10baseT/UTP)
status: active
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
inet 127.0.0.1 netmask 0xff000000
wan0: flags=51<UP,POINTOPOINT,RUNNING> mtu 1500
inet 219.51.254.45 --> 219.51.254.46 netmask 0xfffffffc
%>

(the actual output has tabs to make the formatting a little prettier)

Re:How about live /etc/rc.conf changes?

[changelingyahoo.com]

The quick answer is "Yes, you can." In FreeBSD 5 for instance you can change a line in rc.conf and then just rerun the script for the daemon that corresponds to it. It's a bit like the init.d scripts in Linux except with a big global variables file. In FreeBSD 4 you can do it as well, but if I recall the scripts in FreeBSD 4 often lump several daemons together into a single file so you might end up restarting more than one daemon. I may be wrong, though. Brian

GNU ifconfig - What?

[Anonymous Coward]

There is no "GNU ifconfig". Linux has it's own version which is probably based on an old BSD version, or, maybe written from scratch.

% ifconfig -V
net-tools 1.60
ifconfig 1.42 (2001-04-13)

You can tell it's not GNU because it doesn't spout on about the GPL everytime you run it.

Re:How about live /etc/rc.conf changes?

[phoenix_rizzen]

That's already in there: /bin/sh /etc/netstart

This reads the network settings from rc.conf and reconfigures the interfaces and routes based on that info.

What ever happened to "Small is Beautiful"?

[JohnQPublic]

A yacc grammar? That makes it official, ifconfig is now a contender for the ls Memorial Too Damn Many Options award. Other known entrants include ld, most X applications, and the ever-popular gcc.

Nice to see work on improving ifconfig

[nutznboltz]

Now if only the ARP interface could be improved too. Seems once the API for ARP was an ioctl() that was easy to use. Now try and write some code for *BSD to adjust the ARP table without going

• system("/usr/sbin/arp ...")

and you will see pretty quickly that it's much more complicated than any ioctl()

Conceptually, ARP table entries as routing table entries is great but the API is in need of some serious re-working or a library to hide the complexity.

Linux's iproute2+tc

[szap]

FWIW, Linux 2.4+ has a significantly different way to access and config the kernel's network interfaces using iproute2+tc (using the commands 'ip' and 'tc') that is cleaner than the ifconfig syntax, and supports more advanced routing features (all sorts of firewalling rules and, packets queues, for instance).

ifconfig is just the older, more compatible way to config the interfaces for those who grew up using older Linuxes and other Unices. You can do everything ifconfig + iptables using ip + tc and more.

So before anyone claims that Linux's ifconfig sucks and is too complicated, they've already made a better replacement for it, just needs more documentation and exposure.

Re:Linux's iproute2+tc

[chrysalis]

Please mod this up.

"ip" is definitely great and I really miss that command on BSD systems.

Not only it is way more powerful that ifconfig, it is also easier to use, with a very logical and comprehensive syntax ("ip route add default via 192.168.1.221")

Refactoring "ifconfig" nowadays sounds like a total waste of time IMHO. Hopefully Dragonfly will take a more modern approach.

Re:Linux's iproute2+tc

[jjgm]

"ip" is a well-structured command, although the interactions between iproute2 and ifconfig-based interface aliases confuse people (my usual advice is: one or the other).

"tc" is a complex elephant in considerable need of exposure to someone who both a) cares about qdisc and b) understands OS usability. ip & tc are hardly comparable. The "shapecfg" command is more intuitive, but communicates with a completely separate and underdeveloped kernel subsystem.

iptables then has another syntax to learn, just to drive home the point that these subsystems are not well integrated. You can't do everything iptables/Netfilter can in ip+tc; please don't claim this. Functionally, it's almost orthogonal. Fortunately, there are patches available that permit Netfilter firewalls to hook into iproute2/tc and vice versa.

It's not really a happy situation, and designing complex network behaviour for Linux is still an exercise in trial, error, patch integration, and hours of googling.

Re:GNU ifconfig - What?

[serial frame]

Let's not give the GNU guys any ideas. ;)