Asix ax88772b
-
Hello,
trying to build a home router (with wifi AP) using my netbook samsung n148. I bought 2 ASIX usb NICs based on ax88772b chipset. As far as I see it starts work from freebsd 8.3,
but not for me :-( I installed pfsense 2.1 from this image - pfSense-2.1-BETA0-2g-i386-nanobsd_vga-20121129-1950.img.gz to usb flash. Pfsense detected these nics,
I'm able to add IP addresses on them, can do ping and traceroute. But nothing else. Even DNS queries do not work through these interfaces. Tried to put the internet cable
into onboard card - working perfectly. I haven't freebsd 8.3, so I can't check if this bug present on it. Any thoughts ?
Thanks in advanceP.S. Installed vyatta (linux debian based router) on another usb stick and it works with these cards. Windows 7/8 too.
-
can do ping and traceroute. But nothing else.
Giving the command and system response is almost always more informative than "work/don't work".
-
do not work anything except ping and traceroute, I'll post output of commands here later. Tried ssh and ftp to another host from this interface for example. And unable to connect from internet and intranet to router via this interface using ssh and http
-
unable to connect from internet and intranet to router via this interface using ssh and http
pfSense is a firewall. Default firewall rules block ALL access attempts arriving on the pfSense WAN interface.
Since you didn't mention anything about firewall rules I assume you have default rules. (If not, you had better specify how you have changed them.)
-
I allowed all from any to WAN interface. I have access when changed cables, LAN to ue0 and WAN to msk0. But lost ability to connect to router from LAN.
-
I allowed all from any to WAN interface.
Maybe you didn't reset firewall states after major rule change (see Diagnostics -> States, click on Reset States tab for explanation).
-
I have access when changed cables, LAN to ue0 and WAN to msk0. But lost ability to connect to router from LAN.
You will make it much easier for me (and possibly other readers of this topic) to help you if you settle on a stable configuration, provide details of that configuration (e.g. output of pfSense shell command /etc/rc.banner), details of changes you made to default configuration (e.g. changes to default firewall rules, services you enable etc) and details of commands you issued and the system responses (e.g. On a system connected to the pfSense LAN interface through a switch I saw … [provide command and response]). Since you seem to have connectivity problems I suggest
1. You reboot your pfSense to start over with no memory of previous configuration changes.
2. In a pfSense shell session you ping 8.8.8.8 and post response
3. In a pfSense shell session you ping www.google.com and post responsePfSense is a router but more than a router, it is also a firewall. And so not all interfaces are equal. Consequently, if you switch cables to pfSense around it is highly likely pfSense will behave very differently.
I'll post output of commands here later.
How much later? And which configuration?
-
[2.1-BETA0][root@pfSense.localdomain]/root(8): /etc/rc.banner
*** Welcome to pfSense 2.1-BETA0-pfSense (i386) on pfSense ***WAN (wan) -> ue0 -> v4: 178.150.90.134/24
LAN (lan) -> msk0 -> v4: 192.168.1.254/24
OPT1 (opt1) -> ath0_wlan0 ->1. reinstalled pfsense to new usb flash (using install from memory stick, because switching to read only mode in nanobsd is too slow on this version)
2. [2.1-BETA0][root@pfSense.localdomain]/root(5): ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=51 time=38.760 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=51 time=38.636 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=51 time=38.548 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=51 time=38.515 ms
^C
–- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 38.515/38.615/38.760/0.095 ms3.
[2.1-BETA0][root@pfSense.localdomain]/root(6): ping www.google.com
PING www.google.com (46.28.247.114): 56 data bytes
64 bytes from 46.28.247.114: icmp_seq=0 ttl=60 time=22.534 ms
64 bytes from 46.28.247.114: icmp_seq=1 ttl=60 time=22.479 ms
64 bytes from 46.28.247.114: icmp_seq=2 ttl=60 time=22.411 ms
64 bytes from 46.28.247.114: icmp_seq=3 ttl=60 time=22.713 ms
^C
–- www.google.com ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 22.411/22.534/22.713/0.112 ms4. [2.1-BETA0][root@pfSense.localdomain]/root(7): telnet www.google.com 80
Trying 46.28.247.114…
telnet: connect to address 46.28.247.114: Operation timed out
Trying 46.28.247.89...
telnet: connect to address 46.28.247.89: Operation timed out
Trying 46.28.247.104...
^CI have access when changed cables, LAN to ue0 and WAN to msk0. But lost ability to connect to router from LAN.
You will make it much easier for me (and possibly other readers of this topic) to help you if you settle on a stable configuration, provide details of that configuration (e.g. output of pfSense shell command /etc/rc.banner), details of changes you made to default configuration (e.g. changes to default firewall rules, services you enable etc) and details of commands you issued and the system responses (e.g. On a system connected to the pfSense LAN interface through a switch I saw … [provide command and response]). Since you seem to have connectivity problems I suggest
1. You reboot your pfSense to start over with no memory of previous configuration changes.
2. In a pfSense shell session you ping 8.8.8.8 and post response
3. In a pfSense shell session you ping www.google.com and post responsePfSense is a router but more than a router, it is also a firewall. And so not all interfaces are equal. Consequently, if you switch cables to pfSense around it is highly likely pfSense will behave very differently.
I'll post output of commands here later.
How much later? And which configuration?
-
switched interfaces:
[2.1-BETA0][root@pfSense.localdomain]/root(1): /etc/rc.banner
*** Welcome to pfSense 2.1-BETA0-pfSense (i386) on pfSense ***WAN (wan) -> msk0 -> v4: 178.150.90.134/24
LAN (lan) -> ue0 -> v4: 192.168.1.144/24
OPT1 (opt1) -> ath0_wlan0 ->
logged in to the router via internet, I'm unable to login via local network[2.1-BETA0][root@pfSense.localdomain]/root(2): telnet www.google.com 80
Trying 46.28.247.113…
Connected to www.google.com.
Escape character is '^]'.
get
HTTP/1.0 400 Bad Request
[skiped]Now I can only ping devices on local network
-
sorry, for russian language, but I think you'll take the sense:
C:\Program Files (x86)\Far Manager>ping 192.168.1.144
Обмен пакетами с 192.168.1.144 по с 32 байтами данных:
Ответ от 192.168.1.144: число байт=32 время=7мс TTL=64
Ответ от 192.168.1.144: число байт=32 время=3мс TTL=64
Ответ от 192.168.1.144: число байт=32 время=3мс TTL=64
Ответ от 192.168.1.144: число байт=32 время=3мс TTL=64Статистика Ping для 192.168.1.144:
Пакетов: отправлено = 4, получено = 4, потеряно = 0
(0% потерь)
Приблизительное время приема-передачи в мс:
Минимальное = 3мсек, Максимальное = 7 мсек, Среднее = 4 мсекC:\Program Files (x86)\Far Manager>telnet 192.168.1.144 80
Подключение к 192.168.1.144…Не удалось открыть подключение к этому узлу, на порт 80: Сбой подключенияC:\Program Files (x86)\Far Manager>telnet 192.168.1.144 22
Подключение к 192.168.1.144...Не удалось открыть подключение к этому узлу, на порт 22: Сбой подключенияit is output from laptop on local network, I hope now all is clear.
P.S. local ip switched because pfsense got it via DHCP
P.P.S. these ue0 cards perfectly work on linux and windows -
Thanks for the additional information.
sorry, for russian language, but I think you'll take the sense:
I could probably decode French but Russian is Dutch to me. :-)
I am guessing from the short response that the telnet commands @vlak:
C:\Program Files (x86)\Far Manager>telnet 192.168.1.144 80
Подключение к 192.168.1.144…Не удалось открыть подключение к этому узлу, на порт 80: Сбой подключенияC:\Program Files (x86)\Far Manager>telnet 192.168.1.144 22
Подключение к 192.168.1.144...Не удалось открыть подключение к этому узлу, на порт 22: Сбой подключенияbut I have no idea if they are reporting "timeout", "access refused", "no route" etc
P.S. local ip switched because pfsense got it via DHCP
I presume you mean the switch from 192.168.1.254 to 192.168.1.144 as shown in your first and second use of /etc/rc.banner. It is interesting you mention DHCP here - when did DHCP come into play? On my pfSense 2.1 system /etc/rc.banner reports (in part):```
[2.1-BETA0][admin@pfsense2.test.example.org]/root(12): /etc/rc.banner
*** Welcome to pfSense 2.1-BETA0-pfSense (i386) on pfsense2 ***WAN (wan) -> vr0 -> v4/DHCP4: 192.168.211.217/25
LAN (lan) -> rl0 -> v4: 192.168.217.173/24
v6: 2001:470:1f05:14b3::1/64
OPT1 (opt1) -> ral0_wlan1 ->Note the DHCP tag on the WAN interface report. @vlak: > P.P.S. these ue0 cards perfectly work on linux and windows Thanks. Useful data point. @vlak: > switched interfaces: What did you do here? Switched the cables and interface assignments through the web GUI or pfSense shell option "1) Assign interfaces"? Did you also restart pfSense before performing the tests you did next? (I have found it sometimes necessary to restart pfSense after major changes like that - the routing table seems to get left in a "confused" state. But it is a while since I made a change like that.) @vlak: > logged in to the router via internet, I'm unable to login via local network Logged into pfSense from "local network" to pfSense WAN address? Or logged in so the access attempt entered the pfSense box on the WAN interface? What was reported on the login attempt via local network? Is that the"Russian" report? @vlak: > [2.1-BETA0][root@pfSense.localdomain]/root(2): telnet www.google.com 80 > Trying 46.28.247.113… > Connected to www.google.com. > Escape character is '^]'. > get > HTTP/1.0 400 Bad Request > [skiped] > > Now I can only ping devices on local network Not sure what you mean by this. Access attempts to services like ssh/http on local network from pfSense report an error? If so, what error? I have further questions but I need to take a break just now.
-
Thanks for the additional information.
sorry, for russian language, but I think you'll take the sense:
I could probably decode French but Russian is Dutch to me. :-)
I am guessing from the short response that the telnet commands @vlak:
C:\Program Files (x86)\Far Manager>telnet 192.168.1.144 80
Подключение к 192.168.1.144…Не удалось открыть подключение к этому узлу, на порт 80: Сбой подключенияC:\Program Files (x86)\Far Manager>telnet 192.168.1.144 22
Подключение к 192.168.1.144...Не удалось открыть подключение к этому узлу, на порт 22: Сбой подключенияbut I have no idea if they are reporting "timeout", "access refused", "no route" etc
timeout
P.S. local ip switched because pfsense got it via DHCP
I presume you mean the switch from 192.168.1.254 to 192.168.1.144 as shown in your first and second use of /etc/rc.banner. It is interesting you mention DHCP here - when did DHCP come into play? On my pfSense 2.1 system /etc/rc.banner reports (in part):```
[2.1-BETA0][admin@pfsense2.test.example.org]/root(12): /etc/rc.banner
*** Welcome to pfSense 2.1-BETA0-pfSense (i386) on pfsense2 ***WAN (wan) -> vr0 -> v4/DHCP4: 192.168.211.217/25
LAN (lan) -> rl0 -> v4: 192.168.217.173/24
v6: 2001:470:1f05:14b3::1/64
OPT1 (opt1) -> ral0_wlan1 ->Note the DHCP tag on the WAN interface report. I have linksys router on this network and it gave IP to pfsense :-) @vlak: > P.P.S. these ue0 cards perfectly work on linux and windows Thanks. Useful data point.
switched interfaces:
What did you do here? Switched the cables and interface assignments through the web GUI or pfSense shell option "1) Assign interfaces"? Did you also restart pfSense before performing the tests you did next? (I have found it sometimes necessary to restart pfSense after major changes like that - the routing table seems to get left in a "confused" state. But it is a while since I made a change like that.)
yes, I used "1) Assign interfaces" and changed the cables
logged in to the router via internet, I'm unable to login via local network
Logged into pfSense from "local network" to pfSense WAN address? Or logged in so the access attempt entered the pfSense box on the WAN interface? What was reported on the login attempt via local network? Is that the"Russian" report?
I logged into pfsense via my another internet connection to its WAN ip address. pfsense is inaccessible via ue0 interface using wan or lan ip.
[2.1-BETA0][root@pfSense.localdomain]/root(2): telnet www.google.com 80
Trying 46.28.247.113…
Connected to www.google.com.
Escape character is '^]'.
get
HTTP/1.0 400 Bad Request
[skiped]Now I can only ping devices on local network
Not sure what you mean by this. Access attempts to services like ssh/http on local network from pfSense report an error? If so, what error?
I meant, I am able to connect to 80 port to google.com. It works via msk0 interface.
I have further questions but I need to take a break just now.
rebooting to linux, please inform me if you need some info from me, or I can give you access to this box, please skype me in this case. my skype is vlakua
thanks in advanceP.S. but I think we have an issue with freebsd drivers for asix ax88772b, that is why I posted this message in "Hardware" part of the forum ;-)
-
BTW, I have some experience of using pfsense (I already use 3 pfsense boxes near a half of an year without any problems)
-
P.S. but I think we have an issue with freebsd drivers for asix ax88772b, that is why I posted this message in "Hardware" part of the forum ;-)
Fair enough. I have some sympathy with that suspicion. USB wired NICs are not highly regarded in the pfSense forums. FreeBSD seems to be far more widely used as a "server" operating system than as a "desktop" operating system so I suspect drivers for USB wired NICs don't get much of a workout. When I first created a VirtualBox VM for pfSense I accepted the default type for the emulated NICs (an AMD type) but pfsense wouldn't communicate. After some hours poking around I suspect the NIC driver wasn't tickling the NIC correctly to get it to transmit. Packet captures showed the pfSense NIC was getting frames to transmit but they weren't going any further. When I changed the emulated NIC type to Intel E1000 and made the corresponding change in pfSense configuration it all worked.
Do you think the USB NIC stops receiving? stops transmitting?
Does the pfSense system log report anything on the USB NIC? (watchdog timeout? receive buffer allocation failure?)
I suggest you start an indefinite duration ping to the USB NIC in pfSense and run a concurrent packet capture in pfSense. When the ping stops seeing a response does the packet capture show incoming pings? outgoing pings? nothing? If necessary, try a variety of things, for example, ping for a while, stop it then try a telnet or ssh or web access.
-
Just reading through this thread it looks from the evidence that it is the msk interface that isn't working.
For example
@vlak:[2.1-BETA0][root@pfSense.localdomain]/root(8): /etc/rc.banner
*** Welcome to pfSense 2.1-BETA0-pfSense (i386) on pfSense ***WAN (wan) -> ue0 -> v4: 178.150.90.134/24
LAN (lan) -> msk0 -> v4: 192.168.1.254/24
OPT1 (opt1) -> ath0_wlan0 ->In the above configuration you are able to ping 8.8.8.8 and google.com no problems. So here ue0 seems to tbe working. You don't mention whether you can ping any local addresses via LAN here.
Then:
@vlak:switched interfaces:
[2.1-BETA0][root@pfSense.localdomain]/root(1): /etc/rc.banner
*** Welcome to pfSense 2.1-BETA0-pfSense (i386) on pfSense ***WAN (wan) -> msk0 -> v4: 178.150.90.134/24
LAN (lan) -> ue0 -> v4: 192.168.1.144/24
OPT1 (opt1) -> ath0_wlan0 ->In the above configuration you cannot ping external IPs via WAN but you can ping local IPs. Implying that again ue0 is working and msk0 is not.
Since you aren't using DHCP it is not imediately obvious if the WAN interface is not working at all.
However you also say:
@vlak:logged in to the router via internet, I'm unable to login via local network
Which kind of blows that theory out of the water!
You should check the system logs for any MSK watchdog timeout messages which are a known problem with some NICs and the msk(4) driver.
Steve
-
I've decided to make home router from normal PC, this card is buggy under linux too:
– skiped --
[ 120.369436] asix 1-7:1.0: eth2: asix_rx_fixup() Bad Header Length
[ 120.369913] asix 1-7:1.0: eth2: asix_rx_fixup() Bad Header Length
[ 120.370350] asix 1-7:1.0: eth2: asix_rx_fixup() Bad Header Length
[ 120.370756] asix 1-7:1.0: eth2: asix_rx_fixup() Bad Header Length
[ 120.371181] asix 1-7:1.0: eth2: asix_rx_fixup() Bad Header Length
[ 120.371612] asix 1-7:1.0: eth2: asix_rx_fixup() Bad Header Length
[ 120.372038] asix 1-7:1.0: eth2: asix_rx_fixup() Bad RX Length 1626
[ 120.372473] asix 1-7:1.0: eth2: asix_rx_fixup() Bad Header Length
[ 120.372901] asix 1-7:1.0: eth2: asix_rx_fixup() Bad Header Length
[ 120.373332] asix 1-7:1.0: eth2: asix_rx_fixup() Bad Header Length
[ 120.373763] asix 1-7:1.0: eth2: asix_rx_fixup() Bad Header Length
[ 146.648898] martian destination 0.0.0.0 from 109.86.255.60, dev eth2
[ 171.505176] asix 1-7:1.0: eth2: asix_rx_fixup() Bad Header Length
[ 171.505609] asix 1-7:1.0: eth2: asix_rx_fixup() Bad Header Length
[ 171.506059] asix 1-7:1.0: eth2: asix_rx_fixup() Bad Header Length
[ 171.506487] asix 1-7:1.0: eth2: asix_rx_fixup() Bad RX Length 1955
[ 171.506923] asix 1-7:1.0: eth2: asix_rx_fixup() Bad Header Length
[ 171.507372] asix 1-7:1.0: eth2: asix_rx_fixup() Bad Header Length
[ 171.507797] asix 1-7:1.0: eth2: asix_rx_fixup() Bad Header Length
[ 171.508215] asix 1-7:1.0: eth2: asix_rx_fixup() Bad Header Length
[ 171.508639] asix 1-7:1.0: eth2: asix_rx_fixup() Bad Header Length
[ 171.509093] asix 1-7:1.0: eth2: asix_rx_fixup() Bad Header Length
[ 171.509523] asix 1-7:1.0: eth2: asix_rx_fixup() Bad Header Length
[ 171.509943] asix 1-7:1.0: eth2: asix_rx_fixup() Bad RX Length 1743
– skiped --
my netbook going into reboot when I downloading large file, tried d-link dub-e100 with the same resultmsk0 working without any errors