Network Interface (card) Not Usable

rtwingfield

rtwingfield

I have just swapped a server box to utilize a different main-board that includes an "on-board" "NIC" (network interface device). I'm using the same OS hard drive (FreeBSD v10.1). I have changed the /etc/rc.conf clause from ifconfig_dc0 to ifconfig_ae0 . . .this was the only change from an otherwise previously working system, only now, things to do not work . . .things such as sendmail, ssh, the ntp server, and the BIND name server. I can ping the IP address, but nothing else seems to be recognized.

Previously, I was utilizing a separate NIC card that was recognized as dc0. Why shouldn't the ae0 "interface" (as recognized by the system) work? Also, all information displayed by ifconfig(8) looks normal.
 
Many applications configure their listening interface directly. My #1 suspect would be your firewall.

Code: 
find /etc -type f -exec grep -l dc0 {} \;
find /usr/local/etc -type f -exec grep -l dc0 {} \;
 
aupanner said:
Many applications configure their listening interface directly. My #1 suspect would be your firewall.

Code: 
find /etc -type f -exec grep -l dc0 {} \;
find /usr/local/etc -type f -exec grep -l dc0 {} \;
Click to expand...

. . .well, dc0 has been removed from the "box". Now the on-board interface "card" is identified as ae0.
 
Exactly. He's looking for config files that might refer to 'dc0' directly -- and now erroneously; pf.conf (firewall) would be a prime example.
 
I appreciate your suggestions, . . .but there is no "BSD'ish" software firewall in place . . .only in the Cisco router (an RV016). Nothing has changed there. This system has been running since v4+ . . .early 90's. Again my comment, I only changed a "mother board". Also, I just reinstalled the realtech NIC and now ifconfig identifies both ae0 and dc0 . . .and both are "UP"

The system is just not communicating through either of them.

Where in what logs should I look for problems?
 
Datapanic said:
Maybe a dump of dmesg posted here would help.
Click to expand...

Yes, I look at dmesg, but I cannot connect via ssh; consequently, I cannot efficiently copy and paste to any "windoze" workstation editor such as WordPerfect or Notepad . . .whatever; part of the problem is that ssh (among other things) will not "hookup". Very frustrating.

. . .and BTW, messages looks normal enough.
 
You should be able to use a USB Stick, mount it on this server and copy the output of dmesg to it and then take that info, copy it to whatever it is you are using to post here on this forum and provide the info. You're not providing enough info for anyone to help + you are running a version (10.1) of FreeBSD that has EOL'ed quite a long time ago in computer years...
 
Datapanic said:
You should be able to use a USB Stick, mount it on this server and copy the output of dmesg to it and then take that info, copy it to whatever it is you are using to post here on this forum and provide the info. You're not providing enough info for anyone to help + you are running a version (10.1) of FreeBSD that has EOL'ed quite a long time ago in computer years...
Click to expand...
 
Yes, I know how to mount a USB device, copy files and move them around . . .it's just a PIA to do so. And yes, v10.1 is EOL, but should not be the problem here. . . .been working for two years . . .no changes. I'll just keep working with it. Thanks anyway.
 
OK . . .I've taken time to copy the dmesg and rc.conf files for perusal by others. Perhaps a second set of eyes will see something that I've overlooked.

Thanks again,
RW
 

Attachments

  • 20170228.dmesg.txt
    8 KB · Views: 231
  • rc.conf
    3.2 KB · Views: 246
Additionally . . . I've included the output of ifconfig for perusal by others. Perhaps a second set of eyes will see something that I've overlooked.

Thanks again,
RW
 

Attachments

  • ifconfig.txt
    929 bytes · Views: 280
In your rc.conf file, shouldn't the defaultrouter be 162.202.233.80? You have 162.202.233.81 which is the same as the NIC IP address. You could do anything on the same subnet, but nothing from the outside, since it routes to itself. That's the only thing I can see in the files you provided.
 
Ok, first one: you shouldn't have both ae0 and dc0 configured to the same subnet at the same time. Even if both your network cards were working, this would make your machine unpredictable, to say it gently. In general, when you are testing one network interface, it helps if you comment out the others from rc.conf.
Second, your ifconfig output shows that ae0 reports as no carrier, which usually means that there isn't a cable connected, or the cable is broken, not connected at the other end etc.
Code: 
ae0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
   options=82018<VLAN_MTU,VLAN_HWTAGGING,WOL_MAGIC,LINKSTATE>
   ether 00:22:15:7f:b9:2f
   inet 162.202.233.81 netmask 0xfffffff8 broadcast 162.202.233.87
   nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
   media: Ethernet autoselect (none)
   status: no carrier
Now, if you have checked the cable, and it is ok, you can do a bit more testing, in order to figure out if there is something wrong with ae0 hardware or driver. This is not a certain way to figure out things, but it has helped locate problems in the past.
Try a # ifconfig ae0 down, followed by # ifconfig ae0 up, and then check the status with # ifconfig ae0. Does it show "status: active" instead of "status: no carrier"? Congratulations, you have just found out that the driver is not working correctly. Look for open problem reports (PRs) for the ae(4) driver. If you find one that describes your problem, look for a solution / workaround / patch in it. If no workaround exists, add your details to the PR. If there are no open PRs for the ae driver and the problem you have, submit a PR.
 
I can and will disable/remove either the dc0 or ae0 interface. (BTW, yes I understand that no carrier indicates that the cable is/was not connected)I will apply your suggestions and test the interfaces using ifconfig. Also I will check the kernel for appropriate drivers. Unfortunately, will have to wait for tomorrow or next day. Afternoon is scheduled with AT&T U-verse tech appointment that may involve modem interference/replacement . . .assoc/w new bundled account. They promise that I should continue to use my Motorola NVG589 modem with no reconfiguration. We'll see . . .hope so!

Thank you so much!
 
You must log in or register to reply here.
Back
Top