| |||||||||||||
Williams: That's when I reach for my revolver...Williams: That's when I reach for my revolver...Posted Mar 24, 2009 1:04 UTC (Tue) by ras (subscriber, #33059)Parent article: Williams: That's when I reach for my revolver...
For the most part a wonderful article. It should be mandatory reading for the people who design these bloody modems. It never ceases to amaze me how we engineers can make a simple thing, such as sending a data stream over a wireless connection so unnecessarily complex.
But he lost me at the end when he said:
> But thatÂ’s why NetworkManager rocks; we pony up the cash to make sure our shit works.
He must be living in some parallel universe. I have _never_ had the good fortune to see NetworkManager work as it supposed to.
(Log in to post comments)
Williams: That's when I reach for my revolver... Posted Mar 24, 2009 2:03 UTC (Tue) by drag (subscriber, #31333) [Link]
I think his point is that he and the 'NM crew' are actually going through the effort to get this shit working, which nobody else is really doing. At least nobody working on making it easy for users to auto-configure this stuff.
This 'modem' effort is relatively recent push on the part of the network-manager folks.
Previously they concentrated on 802.11 wireless and that sort of thing and thus far, as my personal experience can tell, that stuff works very well now.
Of course it is not perfect, but it is much better then the nightmare configuring Fedora for multiple networks used to be. (hell, getting my workmate's Motorola phone working on it took multiple weeks to get working in a usable manner. And even after that he would have to occasionally log into Windows when it would refuse to connect after a while)
Although I found Debian's configuration stuff worked pretty well for command-line user types. Quite liked it once I figured it out..
I think that Network-manager is more capable, and hacker friendly, then people think it is. Originally it was horrible.. but its had a couple rewrites as far as I can tell. I figure if somebody doesn't know what Network-Manager dispatcher is for then they are probably missing out on some cool possibilities.
The only thing that has been missing out for me is good command line tools, but they seem to be fixing that.
Williams: That's when I reach for my revolver... Posted Mar 24, 2009 10:22 UTC (Tue) by dcbw (guest, #50562) [Link]
I recently had to fix a bug in NM 0.3 in RHEL4. Yes, old versions were pretty bad; but that's always the case with release-early/release-often OSS software. If you don't get it out there and get people using & testing it, it doesn't get better.
Was having that discussion the other day with somebody too... With Mac OS X for example, you might actually be able to create new software that doesn't need to go through a few iterations before it's actually useful to most people, becuase there isn't as much variation in hardware or OS.
But with Linux, so many people use it in so many configurations, and with so much hardware (and so many drivers of differing quality), that if you don't release stuff early and get people testing it, you'll just go through the same pain whenever you release it later.
Williams: That's when I reach for my revolver... Posted Mar 24, 2009 10:09 UTC (Tue) by dcbw (guest, #50562) [Link]
If NM 0.7 hasn't worked for you, and you're using upstream in-kernel device drivers (not -staging crap), then I'd love to hear from you about what your problem is. If you're using NM 0.6, you probably want to upgrade to a newer distro or version that uses NM 0.7.
*Most* of the problems NM has are caused in whole or in part by bad drivers, and that's why its important to have the code so we can fix those drivers. Binary drivers, on the other hand, cannot be fixed, and no maintainable solution can be had by working around their bugs.
And of course there are bugs in NetworkManager, and features that people want that aren't yet implemented. For example, when the wifi connection fails (timeout, AP forcibly disconnected you, you loose signal, etc) nm-applet will pop up the "Type In Your Key" dialog. People hate that. I understand why. The underlying cause was either (a) the driver failed, or (b) the key was wrong, or (c) the access point is crap. So I'm going to work around that by making NM Just Try Harder.
But there comes a point when Just Try Harder fails, because the driver or hardware have problems, and NM just can't work around it any more. Then we get to fix the driver anyway, which we should have done the first time around anyway.
Williams: That's when I reach for my revolver... Posted Mar 24, 2009 23:46 UTC (Tue) by ras (subscriber, #33059) [Link]
I avoid NM now, so I can't really give you the sort of information you need. Actually my usual response to finding something is somewhat nicer than that. I find the bug and then send in a bug report + patch. I can only give you my experience with NM.
My first clash with NM was when someone complained to me they were not getting a DHCP lease. At the time I didn't even know what NM was, or that it was running, but soon found out when I used my the normal tools to debug the problem (ip, ping, dhclient, etc), and then something was undoing my changes. Things obviously changed, but the configuration files for those tools were untouched. Weird, it was like there was a ghost in the machine. Sniffing around I noticed some of the daemons had connections to dbus, which was a new development. I dumped the dbus messages, and eventually the path lead to NM. So it appeared someone had decided to redesign the entire configuration system for networking, moving away from configuration files I could look at in conjunction with man pages and make some sense of. Instead I was confronted with undocumented babble flying across a software bus. You can probably tell how impressed I was with that development.
Still, the solution was simple enough. Disable NM manager, debug the problem as I would normally, then re-enable NM. The problem was unrelated to NM - it was a bug the in firmware of a wireless router. The only issue NM caused was one of visibility - while NM was running it was impossible to tell at what point things were going wrong.
My second clash with NM was on a machine that has a broken wireless switch. Ie it had an internal wireless card that was fully functional, but because of the broken switch you could not turn it on. The owner plugged in a second wireless card, which worked perfectly when I configured it manually. Network manager refused to do anything with the second wireless card. I considered finding the bug in NM, but then visions of all those dbus interconnections rose up and I thought better of it. Any event driven daemon with its fingers in that many pies was probably a nightmare inside. So I just blacklisted the first wireless card, and NM was happy.
There were other clashes whose details escape me now, but suffices to say I have never had a machine which NM "just worked" on. There was always some situation in which it bugged out. Admittedly I tend to work on problems which have defeated others, so the machines tend to have some kink. But not the final one, which occured last weekend. It was a newly installed Ubuntu 8.10 machine. The owner wanted to use one of those 3G USB dongles described the article. To NM's credit the dongle just worked. Having proved the dongle worked we disconnected it, and asked NM to reconnect to 802.11. Do you think it would do that? Nope. Again I had not trouble doing it manually, NM wouldn't. In the end I just told the guy to reboot his machine if he wanted to change from 3G to 802.11.
So now we come to this 3G modem thing. It is great you NM guys are working on it. But what have you produced? I haven't looked, but is it a generic tool we can all use to probe these things, or some code deep within the guts of NM that only NM can use? It is not just an NM problem. Servers and openwrt boxes also have this problem, and they don't run NM.
Williams: That's when I reach for my revolver... Posted Mar 24, 2009 13:05 UTC (Tue) by dwmw2 (subscriber, #2063) [Link] "He must be living in some parallel universe. I have _never_ had the good fortune to see NetworkManager work as it supposed to."I was saying that a year or so ago, but I've changed my mind. Since then, I have had it working relatively sanely on a few machines. It is getting better. That isn't to say there aren't still some problems though — the lack of support for Bluetooth DUN and PAN is painful, although hopefully that should be fixed soon. Watching the system automatically unmount all my NFS file systems while I was in the middle of a 'yum update' from NFS, just because there was a brief power glitch to the Ethernet switch, wasn't a particularly fun experience either...
Williams: That's when I reach for my revolver... Posted Mar 24, 2009 13:21 UTC (Tue) by dcbw (guest, #50562) [Link]
Just for you David, I got an SE phone with DUN that works on T-Mobile's HSDPA network where I already have an unlimited data plan. So now I have the ability to easily debug and fix issues with Bluetooth.
Williams: That's when I reach for my revolver... Posted Mar 24, 2009 13:25 UTC (Tue) by dwmw2 (subscriber, #2063) [Link]
Cool. Does it do PAN too? Although PAN isn't particularly hard to set up on another Linux box...
Williams: That's when I reach for my revolver... Posted Mar 24, 2009 13:37 UTC (Tue) by dcbw (guest, #50562) [Link]
No, it doesn't do PAN, but adamw is shipping me a HTC WinMo phone that does.
Williams: That's when I reach for my revolver... Posted Mar 24, 2009 13:36 UTC (Tue) by dcbw (guest, #50562) [Link]
And I'd like to point out that largely *because* NetworkManager usually doesn't work around stupid drivers and bad infrastructure, but instead encourages developers (including myself) to fix that infrastructure and drivers, we've come quite a long way in driver quality over the past few years.
NetworkManager is both the carrot and the stick. If NM just worked around broken stuff and proprietary drivers, it would be a hacktower of doom and we may still be stuck largely in 2006-wireless land.
Examples of driver/stack fixes due to NetworkManager:
- mac80211 adhoc mode association event and ibss merging timeout fixes
|
|||||||||||||