Date: Thu, 13 Dec 2001 20:47:47 +0100 From: "Anthony Atkielski" <anthony@freebie.atkielski.com> To: "Ryan Thompson" <ryan@sasknow.com> Cc: "FreeBSD Questions" <freebsd-questions@FreeBSD.ORG> Subject: Re: Uptime not so good after all -- why does my net connection go dead? Message-ID: <000901c1840f$0bdad070$0a00000a@atkielski.com> References: <20011213122631.L94416-100000@catalyst.sasknow.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> Yes, and it should, barring hardware problems, > pilot error, or extended power outage, or > managerial downtime. I hope so. It has performed flawlessly for the past two weeks. Of course, it didn't actually crash; I booted it. But I couldn't figure out a way to change the IP address to which my NIC interface was bound on the fly. I tried undoing the original address with ifconfig, then adding the new address with ifconfig, but programs on the system (sendmail, ping) still sent out packets with the old address as source, so I finally ran out of ideas and changed the hosts and rc.conf files and rebooted. If there is a way to do what I wanted without a boot, I could have continued running. > If the problem is with your LAN, you need to go > to the link layer... With what tools? I tried tcpdump; it only printed summary lines of information and I didn't know if there was an option to force more detail. I can't monitor the interface from my other machine because the two machines are on a switch and don't see each other's traffic, even in promiscuous mode. > From the router, AND the NT machine, try arp > lookups for the FreeBSD machine's public IP address. Yes, all MACs correspond. > On the FreeBSD box, put your NIC in promiscuous > mode and start analyzing frames. What actually > gets sent out on the wire? What tool do I use to capture (and hopefully interpret) that data? > Is the machine seeing the IP packets, but not > actually passing them up to the transport layer? > Or maybe it just isn't sending anything out? That's what I'm not sure of. What I did with tcpdump appeared to show that it was sending out packets but getting no response; but depending on where tcpdump picks that up, it may or may not actually be true. It did not appear to see packets coming in. > I assume your IP address and netmask are set > correctly with ifconfig(8)? Does the router > agree with you in terms of netmask? I double-checked and there was a discrepancy. The router and the Windows machine had a mask of 255.0.0.0, whereas the FreeBSD machine had a mask of 255.255.255.0. I changed all the masks to 255.255.255.0, and then the original IP address mysteriously started working again (it had refused to work even after multiple boots of both FreeBSD and the router prior to that). However, I am very wary, as I've been convinced that I had "fixed" the problem before, only to see it come back to haunt me again (as it did today). How would a discrepancy in the masks cause the interface to abruptly freeze after two weeks? > The output of `netstat -rn` would be extremely > helpful. The output and network config of the > router would also be helpful. I had not tried netstat on this occasion, but I had looked at it in the past and everything seemed okay. The current output looks like this: freebie# netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 10.0.0.30 UGSc 3 10 xl0 10/24 link#1 UC 0 0 xl0 => 127.0.0.1 127.0.0.1 UH 1 12 lo0 Internet6: Destination Gateway Flags Netif Expire ::1 ::1 UH lo0 fe80::%xl0/64 link#1 UC xl0 fe80::%lo0/64 fe80::1%lo0 Uc lo0 ff01::/32 ::1 U lo0 ff02::%xl0/32 link#1 UC xl0 ff02::%lo0/3 freebie# NB: 10.0.0.30 is obviously the address of the router. > Try plugging your FreeBSD machine directly into > a port on your router, and unplugging everything > else (except your uplink :-). If THIS works, > then another device on the wire is misbehaving. I've done that on previous occasions ... no effect. > This suggests that either something is wrong > with ARP, and/or the routing tables on the > FreeBSD machine or the router. I suspected ARP, but it looks okay; everyone has the correct MAC for everyone else. The routing is ultrasimple: anything not in 10/24 goes through 10.0.0.30 (the router) to the outside world. > I'd hardly be "biting the bullet" after 2 weeks: Well, it's two more weeks I have to wait to reach the previous record. > $ uptime > 12:41PM up 261 days, 9:56, 3 users, load averages: > 2.37, 2.46, 2.42 > $ uname -a Cool! > After 10 months or so, I think twice about rebooting. > In this time, this machine has survived two power > failures, several brownouts, one particularly memorable > surge, a dead CPU fan, experimental code which resulted > in a fork bomb that filled up the proc table, exhausted the > swap space, and killed just about everything that was running on the > machine, not to mention the abuse it takes from all > of our web clients :-) So how do you replace the dead CPU fan without booting the machine? Don't you keep the machine on a UPS? > And, 261 days isn't anywhere near the potential a > properly maintained FreeBSD system can achieve, but > it definitely shows it is sustainable. Well, we shall see. I've been trying to do everything without booting the machine, just to prove that it is possible (needless to say, this would be an exercise in futility on Windows--just a slight change to the network configuration typically mandates a boot). > FWIW, you most did NOT have to reboot the FreeBSD > machine :-) Okay, so what's the correct way to switch the primary IP address of the machine on the fly? I searched all over on the Web, but didn't find anything that cleared described a procedure, and I couldn't wait too long because mail was backing up for the machine. > Sure, send answers to the questions I've posed, and > we'll be able to get much closer to an explanation. See above. Any anomalies? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?000901c1840f$0bdad070$0a00000a>