Bug 206143 - DLINK DUB-E100 revision C1 can't reach destination
Summary: DLINK DUB-E100 revision C1 can't reach destination
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: usb (show other bugs)
Version: 10.1-RELEASE
Hardware: amd64 Any
: --- Affects Many People
Assignee: freebsd-usb mailing list
Depends on:
Reported: 2016-01-11 22:45 UTC by Mantas
Modified: 2016-08-08 08:14 UTC (History)
2 users (show)

See Also:

pcap file (15.22 KB, application/vnd.tcpdump.pcap)
2016-01-12 15:05 UTC, Mantas
no flags Details
pfctl rules with ue0 (7.64 KB, text/plain)
2016-01-20 19:15 UTC, Mantas
no flags Details
pfctl rules wtih ale0 (7.65 KB, text/plain)
2016-01-20 19:16 UTC, Mantas
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mantas 2016-01-11 22:45:48 UTC
I have USB to Ethernet adapter DLINK DUB-E100 revision C1. I was trying to use it on newest pfesense release, which is based on freebsd 10.1-RELEASE-p25. After installing pfsense, I could ping the system, but was not able to reach it's webpage, which I was able to do via other ethernet port. I was searching for solution and found this topic on pfsense forum:

Then I created a ticket on their bug tracker, but reply was "it's not our issue, contact freebsd support".

That is what I am doing right now. If you need any additional information feel free to tell me, but keep in mind that I have never used FreeBSD before.

Thanks in advance.
Comment 1 Hans Petter Selasky freebsd_committer 2016-01-12 08:44:05 UTC

Did you configure the firewall and routing settings correctly?

What does "ifconfig ue0" output?

Is your device detected as a network adapter?

Which version of FreeBSD are you using?

Comment 2 Mantas 2016-01-12 14:09:01 UTC
(In reply to Hans Petter Selasky from comment #1)
Mister, it's nor firewall, nor routing settings, it's something with the drivers specificaly with C1 revision of this device.

I'm not the only one having this problem.

All your questions refer it's something wrong with configuration. It's not.

And yes, device appears as ue0.

FreeBSD version I wrote in first post, but can repeat it: 10.1-RELEASE-p25
Comment 3 Hans Petter Selasky freebsd_committer 2016-01-12 14:18:38 UTC

Sorry if you have to repeat yourself.

Did you try to make a tcpdump trace showing why traffic is not passing like expected: "tcpdump -i ue0 -pn -w test.pcap"

The only I can think of which can be wrong is the multicast filters, which might block traffic if not set correctly.

Comment 4 Hans Petter Selasky freebsd_committer 2016-01-12 14:20:04 UTC
Also, did you try to enable debugging for your driver?

sysctl -a hw.usb | grep debug

Comment 5 Hans Petter Selasky freebsd_committer 2016-01-12 14:22:33 UTC
If the debug knob is not there, you'll have to rebuild the network driver you are using like this:

cd /usr/src
make -C sys/modules/usb/xxx -m $PWD/share/mk DEBUG_FLAGS="-DUSB_DEBUG" clean
make -C sys/modules/usb/xxx -m $PWD/share/mk DEBUG_FLAGS="-DUSB_DEBUG" all
make -C sys/modules/usb/xxx -m $PWD/share/mk DEBUG_FLAGS="-DUSB_DEBUG" install

Thank you!

Comment 6 Mantas 2016-01-12 15:05:59 UTC
Created attachment 165435 [details]
pcap file
Comment 7 Mantas 2016-01-12 15:09:03 UTC
(In reply to Hans Petter Selasky from comment #5)
Debug was set to 0, so I have to rebuild it, but there is no directory /usr/src, since it's pfsense, not full freebsd.
Comment 8 Mantas 2016-01-12 16:13:02 UTC
(In reply to Hans Petter Selasky from comment #4)
systctl hw.usb.debug=1
it changed from 0 to 1, so it means the knob is there, right?
Comment 9 Hans Petter Selasky freebsd_committer 2016-01-12 16:19:36 UTC
(In reply to Mantas from comment #8)
No, that's the wrong one. You should find one like:


Or something like that.

Comment 10 Mantas 2016-01-12 16:21:55 UTC
There is no axe.debug, but there also is no /usr/src/ directory in pfsense. How should I procede?
Comment 11 Hans Petter Selasky freebsd_committer 2016-01-12 16:23:53 UTC
In your test.pcap, there are a lot of destination unreachable messages. It might indicate a misconfiguration of some kind. Traffic seems to be flowing both in and out of the adapter, so I think the problem is not there.

Did you have a look at test.pcap with wireshark?

Comment 12 Hans Petter Selasky freebsd_committer 2016-01-12 16:24:36 UTC
(In reply to Mantas from comment #10)

Can you show me the output from:

sysctl hw.usb




dmesg | grep ugen

Comment 13 Mantas 2016-01-12 16:48:33 UTC
(In reply to Hans Petter Selasky from comment #12)

ath0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 2290
	ether 00:25:d3:65:ab:ab
	media: IEEE 802.11 Wireless Ethernet autoselect (autoselect)
	status: no carrier
ale0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
	ether 00:26:18:f9:e5:38
	inet6 fe80::226:18ff:fef9:e538%ale0 prefixlen 64 scopeid 0x2 
	media: Ethernet autoselect (none)
	status: no carrier
pflog0: flags=100<PROMISC> metric 0 mtu 33144
pfsync0: flags=0<> metric 0 mtu 1500
	syncpeer: maxupd: 128 defer: on
	syncok: 1
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
	inet netmask 0xff000000 
	inet6 ::1 prefixlen 128 
	inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 
enc0: flags=0<> metric 0 mtu 1536
ue0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
	ether c4:a8:1d:6d:ac:af
	inet netmask 0xffffff00 broadcast 
	inet6 fe80::1:1%ue0 prefixlen 64 scopeid 0x7 
	media: Ethernet autoselect (100baseTX <full-duplex>)
	status: active

hw.usb.xhci.streams: 0
hw.usb.no_boot_wait: 0
hw.usb.no_suspend_wait: 0
hw.usb.no_shutdown_wait: 0
hw.usb.debug: 0
hw.usb.template: 0
hw.usb.usb_lang_id: 9
hw.usb.usb_lang_mask: 255
hw.usb.power_timeout: 30
hw.usb.no_cs_fail: 0
hw.usb.full_ddesc: 0
hw.usb.uath.countrycode: 0
hw.usb.uath.regdomain: 0
hw.usb.urtw.preamble_mode: 2
hw.usb.ucom.cons_unit: -1
hw.usb.ucom.cons_subunit: 0
hw.usb.ucom.cons_baud: 9600

ugen3.1: <Intel> at usbus3
ugen2.1: <Intel> at usbus2
ugen1.1: <Intel> at usbus1
ugen0.1: <Intel> at usbus0
ugen6.1: <Intel> at usbus6
ugen5.1: <Intel> at usbus5
ugen4.1: <Intel> at usbus4
ugen7.1: <Intel> at usbus7
ugen7.2: <vendor 0x2001> at usbus7
ugen3.2: <Chicony Electronics Co., Ltd.> at usbus3
Comment 14 Mantas 2016-01-12 16:54:29 UTC
(In reply to Hans Petter Selasky from comment #11)
It just can't be any misconfiguration.

All I do is is set ale0 interface as my lan interface. Everything works fine
Then I do factory reset and configure ue0 as my lan interface. I am only able to ping destination address, but can't reach any webpage.

TLDR: ale0 set as lan Works
ue0 set as lan doesn't work

Same is if i set ale0 as wan interface. I can perfectly reach any destination from router.
But when I do it with ue0, nothing works.
Comment 15 Hans Petter Selasky freebsd_committer 2016-01-12 19:42:40 UTC

I suspect maybe pfsense doesn't recognize the ue0 properly and sets up some firewall rules which block the webpage access. Can you check the statistics for the firewall - dropped packets.

Comment 16 Hans Petter Selasky freebsd_committer 2016-01-12 19:44:44 UTC
Is there something like "ipfw2 show" or "ipfw show" in the command list of your pfsense installation?
Comment 17 Mantas 2016-01-12 19:47:39 UTC
(In reply to Hans Petter Selasky from comment #16)
#ipfw2 show
ipfw2: Command not found.

#ipfw show
ipfw: Context is mandatory: No such file or directory
Comment 18 Anatoly 2016-01-13 01:10:07 UTC
It seems that pfsense uses pf, not ipfw, so to show everythihg:
#pfctl -s all
you can disable pf firewall:
#pfctl -d
then try to access admin web page. To enable it again:
#pfctl -e
Comment 19 Mantas 2016-01-14 15:23:57 UTC
(In reply to Anatoly from comment #18)
Disabling firewall didn't help
Comment 20 Hans Petter Selasky freebsd_committer 2016-01-14 21:46:29 UTC
It might be the webserver in pfsense is not bound to, so it won't serve connections from non-default IPs.

Try with "nc" aka netcat:

nc -l 80

Does it show anything when you connect via HTTP?

Sorry I cannot help you more.
Comment 21 Anatoly 2016-01-16 01:36:07 UTC
(In reply to Mantas from comment #19)
I see in attached test.pcap file at record 112 that you're trying to connect to port 443 (https) on (pfsence). You ( sending SYN. And something really listens on this port, since you've got SYN, ACK back (rec. 113). But this SYN, ACK obviously never reaches you. All that repeat 3 times. If it isn't firewall blocks those packets, probably they may corrupt for weird reason while traveling back. You may try:
Disable checksum offloading on ue0:
#ifconfig ue0 -txcsum -rxcsum
Switch link to slowest mode:
#ifconfig ue0 media 10baseT/UTP mediaopt half-duplex
But thats really strange since there's no problems with ARP nor ICMP packets. Will it work to ping pfsence with 24-byte packets? >ping -l 24 (on windows); #ping -s 24 (on unixes)
Comment 22 Mantas 2016-01-16 10:54:29 UTC
After trying everything you suggested I have repeated all steps suggested here and doing

#pfctl -d

allowed me to reach the GUI. Don't know why it wasn't working last time I did it, but it might have been an error on my part, so I do apologize for that.

So, after all, is it correct to say that the error is on pfsense end, not freebsd's?
Comment 23 Anatoly 2016-01-19 00:16:44 UTC
Most likely problem is in pf configuration that pfsence gives to pf. Can you show your pf state:
#pfctl -a '*' -s all
Also, you can dump effective pf rules into file 'a':
#pfctl -a '*' -s rules > a
Then re-configure your system, making ale0 as lan. Dump rules into file 'b':
#pfctl -a '*' -s rules > b
Obviously, when you compare a and b only difference you must see is interface names.
Comment 24 Mantas 2016-01-20 19:15:58 UTC
Created attachment 165877 [details]
pfctl rules with ue0
Comment 25 Mantas 2016-01-20 19:16:32 UTC
Created attachment 165878 [details]
pfctl rules wtih ale0
Comment 26 Anatoly 2016-01-21 01:53:16 UTC
I see no problem with rules, but they are referring to two address tables that is used as "blacklists": snort2c and webConfiguratorlockout. Can you show me content of those tables (while ue0 as lan):
#pfctl -t snort2c -T show
#pfctl -t webConfiguratorlockout -T show
And your nat/redirect rules also:
#pfctl -s nat

The other situation I can think of is if ue0 disappears from the system (for some USB related matters) after pf rules was loaded. And when it appears back, pf may have troubles to handle it (although it must). Can you check output of #dmesg or /var/log/messages to see if some USB disconnects of ue0 occurs? Anyway, in such a situations clearing firewall state and reloading rules again may help. You may try:
Just for sure
#pfctl -d
#pfctl -e
Clear pf state tables:
#pfctl -F state
Clear pf address tables (your blacklists e.t.c.)
#pfctl -F Tables
Now you need pf config (rules) file to reload. Simplest is to dump existing rules:
#pfctl -s rules > aa
(it's like previously created 'a', but without anchors information. You may also use 'a' but it needs to remove by hand all "anchor "*" all { }") Check that file isn't empty. This file will not contain nat/redirects, but enough for test.
Or, in FreeBSD default location for pf config that is applied at boot is /etc/pf.conf. You may examine that file to see if it contain similar rules and have right modification date.
Clear everything:
#pfctl -F all
Load rules back:
#pfctl -f aa
See if no errors occurs. Test.