Looks like it was fixed with the last update, Phil.  Thanks for your help!

I hope so, the next?

It can only operate in one mode at a time, AP, station or monitor (not ad-hoc).

Hard to say what other factors might be limiting it. The run(4) driver supports several USB chips so perhaps not all of them have all capabilities. User error!  ::)

Steve

Edit: I hope I made this clear (thought I don't think I did!) that I'm testing this under 2.0.1 so it may be better supported by 2.1. The re-mount delay has stopped me running a 2.1 image at the moment.

OK, error message is gone, that's the good part.

Still have to reboot the system a second time after an upgrade to get VoIP going, web browsing and such works without an extra reboot, so it seems to have to do with UDP traffic???

You're better off reporting them on the packages board here, the maintainers are generally active there and not so much on redmine, they tend to just sit there forever in redmine as most package maintainers never look there.

Hi databeestje,

I just gitsynced & that appears to have fixed the problem.

-Will

Hi databeestje,

It looks like it's all there (based on what I recall about the package version). I can go to the unbound service config pages (services_unbound.php, services_unbound_advanced.php) and even config & start the service…..but I couldn't get it to work.

There were a few commits back in early April that added these files to the snapshot, but that was the last activity I saw.

I was never able to get unbound to work as a package, but I think this integration effort was going to fix my issues at the same time as it was being added....I'm very much looking forward to trying this out!

-Will

Last time I noticed this particular behavior was just a few days ago, on 2.1-DEVEL.

If you set the LAN interface to track the dynamic WAN interface we will automatically setup a DHCPv6 server for the LAN too for DNS and domain.

I agree that we might need to allow for dynamic entries too. It is possible iirc. But for some with dynamic prefixes that is a bit hard to do.

So if you know that your prefix is allocated statically by your ISP you should be fine.

If the prefix your ISP sends you is large enough we also setup DHCPv6 prefix delegation automatically by allocating a small chunk of the /56 or larger.

Done

@rcfa:

@daplumber:

but why is it only pathological when on the WAN port?

Not an answer, just more speculation: Since pfSense 2.x it doesn't need a LAN port, so the system can have N additional NICs, but it MUST have a WAN port. So assume something like an occasional USB bus reset happens, if a LAN port goes away for a short moment, the system may handle that like a hot-plug event for an optional interface. But if the MUST HAVE WAN port disappears for ever so short a moment, it may cause it to throw a fit.

Again, that's just speculation, but given that the WAN port has a special standing, it could relate to that.

You may be on to something here. I just checked and there's a handful of ue0 DOWN then Ups in the dmesg output.

This is an elderly laptop with only two USB 2.0 ports, and a few 1.0 ports that I think are only exposed on a dock that I don't have. Here's the USB (+ serial) and axe0/ue0 related parts of the dmesg -a output:

uhci0: <intel 82801fb="" fr="" fw="" frw="" (ich6)="" usb="" controller="" usb-a="">port 0xbfe0-0xbfff irq 23 at device 29.0 on pci0 uhci0: [ITHREAD] uhci0: LegSup = 0x2f00 usbus0: <intel 82801fb="" fr="" fw="" frw="" (ich6)="" usb="" controller="" usb-a="">on uhci0 uhci1: <intel 82801fb="" fr="" fw="" frw="" (ich6)="" usb="" controller="" usb-b="">port 0xbf80-0xbf9f irq 19 at device 29.1 on pci0 uhci1: [ITHREAD] uhci1: LegSup = 0x2f00 usbus1: <intel 82801fb="" fr="" fw="" frw="" (ich6)="" usb="" controller="" usb-b="">on uhci1 uhci2: <intel 82801fb="" fr="" fw="" frw="" (ich6)="" usb="" controller="" usb-c="">port 0xbf60-0xbf7f irq 18 at device 29.2 on pci0 uhci2: [ITHREAD] uhci2: LegSup = 0x2f00 usbus2: <intel 82801fb="" fr="" fw="" frw="" (ich6)="" usb="" controller="" usb-c="">on uhci2 uhci3: <intel 82801fb="" fr="" fw="" frw="" (ich6)="" usb="" controller="" usb-d="">port 0xbf40-0xbf5f irq 16 at device 29.3 on pci0 uhci3: [ITHREAD] uhci3: LegSup = 0x2f00 usbus3: <intel 82801fb="" fr="" fw="" frw="" (ich6)="" usb="" controller="" usb-d="">on uhci3 ehci0: <intel 82801fb="" (ich6)="" usb="" 2.0="" controller="">mem 0xcddffc00-0xcddfffff irq 23 at device 29.7 on pci0 ehci0: [ITHREAD] usbus4: EHCI version 1.0 usbus4: <intel 82801fb="" (ich6)="" usb="" 2.0="" controller="">on ehci0 pcib4: <acpi pci-pci="" bridge="">at device 30.0 on pci0 pci5: <acpi pci="" bus="">on pcib4 iwi0: <intel(r) pro="" wireless="" 2200bg="">mem 0xcdcff000-0xcdcfffff irq 22 at device 5.0 on pci5 ... uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] ... usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 12Mbps Full Speed USB v1.0 usbus4: 480Mbps High Speed USB v2.0 ... ugen0.1: <intel>at usbus0 uhub0: <intel 1="" 9="" uhci="" root="" hub,="" class="" 0,="" rev="" 1.00="" 1.00,="" addr="">on usbus0 ugen1.1: <intel>at usbus1 uhub1: <intel 1="" 9="" uhci="" root="" hub,="" class="" 0,="" rev="" 1.00="" 1.00,="" addr="">on usbus1 ugen2.1: <intel>at usbus2 uhub2: <intel 1="" 9="" uhci="" root="" hub,="" class="" 0,="" rev="" 1.00="" 1.00,="" addr="">on usbus2 ugen3.1: <intel>at usbus3 uhub3: <intel 1="" 9="" uhci="" root="" hub,="" class="" 0,="" rev="" 1.00="" 1.00,="" addr="">on usbus3 ugen4.1: <intel>at usbus4 uhub4: <intel 1="" 9="" ehci="" root="" hub,="" class="" 0,="" rev="" 2.00="" 1.00,="" addr="">on usbus4 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub3: 2 ports with 2 removable, self powered ... uhub4: 8 ports with 8 removable, self powered Root mount waiting for: usbus4 ugen4.2: <vendor 0x05ac="">at usbus4 axe0: <vendor 2="" 0x05ac="" product="" 0x1402,="" rev="" 2.00="" 0.01,="" addr="">on usbus4 ... miibus1: <mii bus="">on axe0 ukphy0: <generic ieee="" 802.3u="" media="" interface="">PHY 16 on miibus1 ukphy0:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ue0: <usb ethernet="">on axe0 ... ue0: link state changed to DOWN ue0: link state changed to UP</usb></generic></mii></vendor></vendor></intel></intel></intel></intel></intel></intel></intel></intel></intel></intel></intel(r)></acpi></acpi></intel></intel></intel></intel></intel></intel></intel></intel></intel></intel>

The "Root mount waiting for: usbus4" is interesting. I never noticed that before. I don't understand that given that root is on Pri/IDE.

Are you thinking I could put some kind of "hint.[driver].[number].irq=[number]" in loader.conf or something?

FreeBSD mybox 8.3-RELEASE-p2 FreeBSD 8.3-RELEASE-p2 #1: Fri Jun 1 07:15:47 EDT 2012 root@FreeBSD_8.3_pfSense_2.1.snaps.pfsense.org:/usr/obj./usr/pfSensesrc/src/sys/pfSense_SMP.8 i386

ntpd working. Yay!

Sweety ! Ill call them baby-jumbo-frames  from now !:)  This term is just way to cool to not use it, hehe :))

Hey thank you for the link :)  Im going to pull out my goodold mac for this!
After all we will (hoperfully) have less nat in the future, so it will be easier with such configurations.
hanD!

https://github.com/bsdperimeter

Given that is only an issue with tracking snapshots, I doubt anyone would want to code it. But if the code happens to appear, we'd probably include it.

Deciding not to use an update that is an actual 'official' update would never be recommended, as the previous versions are not generally supported once a new version is out, and typically include beneficial security updates.

And FYI- even if you don't see changes in the commit log you liked that doesn't mean that there aren't other changes, for example yesterday we picked up fixes for two FreeBSD security SA's (openssl again, and crypt) but because we track the security branches automatically, nothing would show up in our commits for that.

@ryates:

@jimp:

If a package doesn't work for a platform/version, we remove it from the list. We only list the packages that are available for a given platform, if you see it, it's supposed to work.

Thanks for the explanation, as I too was unsure.  Given what you write (and accepting that dev snaps might violate expectations), the version column is quite superfluous and could be removed. Simplicity is always good if possible.

Maybe replace it with "package type" at least for whatever time it takes until packages are using the new package system…

You're correct about the client control, which is Cisco's pitch for their "enhanced" client software. However it's all about the order of "default" in the routing table. You're also correct that the "provide a list of Networks" checkbox was responsible for the "split_network includes" in the generated racoon.conf.

Thanks for the reply jimp! It would have saved me some time…  :P  ::)  ;D I did finally solve my own problem before I read the reply here, so herewith the snaps of the settings I used. These work for non-split tunneling in iOS and OS X native clients. (Although both can be monkeyed with from the client end.)


ok, selective interface binding is back! It may not show up until tomorrow's snapshots because one was already building when I committed it. But a gitsync would pull it in.

Might need some testing to ensure it's doing the right thing. From the logs and sockstat output it appeared to be working as expected, but some other input would be helpful.

It would also be helpful to know if, under Status > NTP, you get an active peer with interface binding setup. I still did, but I'm curious to know if anyone has issues.