Ifconfig not changing media
First off, I'm loving 2.0 so far :)
Sorry if my explanation gets long winded. I'm relatively new to BSD/Unix/Linux but I know enough to "poke around".
I've been running PFsense 1.2.3 for about a year and a half until recently my usb/ethernet adapter died, forcing me to get a new one. I know well enough about hardware compatability so I made sure to research before I bought anything. I recently bought a USB/ethernet adapter based on the AX88178 chipset, which from what i read was supported under BSD. Unfortunately I didn't read close enough, not realizing that it was only really supported in FreeBSD 8.0. It appeared in 1.2.3 as "axe0", detected when it was up or down, but beyond that, it couldn't do much else. I read further and came to the conclusion I had to upgrade to 2.0 (I've been looking for an excuse to try it out anyways but never got the motivation) for it to work right.
Anyways, I upgraded to 2.0 20110301-xxxx and it worked just fine. It displayed as 1000baseT full duplex in the dashboard and iperf had it running at about 800Mb.
Come this morning the connection was dead and I had to reboot the router every five minutes to get the connection working. I upgraded the firmware to 2.0 20110302-0819 and now the interface will not switch out of 10baseT/UTP half-duplex. I've reset the settings back to factory, ran "ifconfig ue0 media 1000baseT mediaopt full-duplex" (which are options when running "ifconfig -m"), changed the settings in /cf/conf/config.xml and removed the cache file.
Still, the dashboard displays the interface at 10baseT/UTP <half-duplex>and the output from ifconfig seems slightly misleading (the media line doesn't seem quite right):
ue0: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500 options=80000 <linkstate>capabilities=80000 <linkstate>ether 00:0e:c6:88:62:46 inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255 inet6 fe80::20e:c6ff:fe88:6246%ue0 prefixlen 64 scopeid 0x6 nd6 options=3 <performnud,accept_rtadv>media: Ethernet 1000baseT <full-duplex> (10baseT/UTP <half-duplex>) status: active supported media: media autoselect media 1000baseT mediaopt full-duplex media 1000baseT media 100baseTX mediaopt full-duplex media 100baseTX media 10baseT/UTP mediaopt full-duplex media 10baseT/UTP media none</half-duplex></full-duplex></performnud,accept_rtadv></linkstate></linkstate></up,broadcast,running,simplex,multicast>
I did notice bug #845 on the bug tracker and I'm not sure if my problem could be caused by it, or if I'm just missing something blatantly obvious due to my inexperience with FreeBSD. Any help would be greatly appreciated.</half-duplex>
The ifconfig output shows what is configured, and what is actually in use. The default is not 1000baseT, but autoselect.
In the output:
media: Ethernet 1000baseT <full-duplex> (10baseT/UTP <half-duplex>)</half-duplex></full-duplex>
That really means "I want to use 1000baseT <full duplex="">but the media is actually running at 10baseT/UTP <half-duplex>".
Check the device on the other end, the cable, etc, but really I wouldn't expect all that much out of a USB ethernet dongle. autoselect is built into the gigabit spec, and you should never hardcode only one end of a connection.
If you hardcode one side you have to hardcode the other as well. If you don't have a managed switch, autoconfigure is required.</half-duplex></full>
Thanks, you were right. 10baseT is what the interface is being set at by default during startup/after being reconnected. After running "ifconfig ue0 media autoselect" it automatically switched to gigabit. It just needs to be run every time the device is restarted.
However, my main issue is that the card itself is hanging, forcing me to either restart the router or disconnect/reconnect the USB, run ifconfig autoselect, and reassign the interfaces in order to get traffic flowing again. In general use the problem will occur anywhere from once every other day to four times a day. I don't remember where I found it, but I was able to dig up the original freebsd bug report behind the final patch linked to in bug #845. The symptoms and the solution before the patch are the same as what I am experiencing.
I know USBs don't have the greatest reputation for being stable in the long run but I don't believe this to be a device problem. Attaching the device to my Windows test box and copying a 100GB file over it had no problems. Whereas SCPing an 8GB file from pfSense caused the device to hang in under a minute.
If this patch gets implemented in pfSense and you need anyone to test it, I'd be glad to help out. ;)
No other suggestions come to mind, other than avoiding USB ethernet dongles…