@cmb:

Works here, with the exact same config you showed, and different ones.

The telling log there is "address already in use" - something is bound to UDP port 1900 already, that's why it's failing to start. You have OpenVPN or something else configured on port 1900? Check the output of "sockstat -4" for 1900.

Yeah, it's me. I had a feeling it was Java or Mombo. I am running those to run the Ubiquiti Unifi controller software on my home router. I need to figure out how to change the port on one of the two and restart.  Thanks for the help. This was useful!

my serial client i upgraded that to latest version, played with all the possible flow control settings but still same.

if u say the alix is dead or the adapter is dead then in those cases nothing should be working at all on serial at all but then y is it that just those 2 sections input is not accepted and everywhere else it works fine, how can it not be broken when 2.1.x versions work fine with same alix and adapter?

(still probably ~200-250 ms I'd guess)

C:\Users\phil.davis>ping pfsense.org Pinging pfsense.org [208.123.73.69] with 32 bytes of data: Reply from 208.123.73.69: bytes=32 time=314ms TTL=43 Reply from 208.123.73.69: bytes=32 time=315ms TTL=43 Reply from 208.123.73.69: bytes=32 time=309ms TTL=45 Reply from 208.123.73.69: bytes=32 time=336ms TTL=45 Ping statistics for 208.123.73.69:     Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds:     Minimum = 309ms, Maximum = 336ms, Average = 318ms

The above is at the better end, from the office on a good quality connection. Typically latency to the USA is from 300 to 400ms, but there are times when it gets worse - often in the evening (6-10pm) when there seems to just be bandwidth bottleneck in/out of Nepal - too many people sitting at home eating rice and lentils while watching YouTube :)

I will try some dummynet tweaking delay and packet loss to make it break, since as you say it would be good to know where the limits are.

IMHO this thread is no longer an impact on 2.2.3 - the 5 second delay works fine for me from Nepal as long as I have an ISP that actually provides a reliable connection. So it should work for anyone else on the planet as long as their ISP also gives decent service.

The only exception I can think of is satellite - are there many pfSense installs with the main/only WAN hanging off the end of a satellite link?

@jimp:

Are you certain that config.xml was restored from the GUI using diag_backup.php?

I'm pretty sure I have not more than 2-3 beers before restoring the config. :D

@jimp:

If there are other issues, I'd like to hear about them, are they in other threads? I haven't been monitoring the forum closely the last few days.

Well, I'm trying to get in touch with the pfBlockerNG author to see what he thinks; seems he's AWOL at the moment.  ;D Basically, I have a base64-encoded exclusion list in the config that gets ignored all of a sudden. The only change there being a gitsync a couple of days ago.

Do you have a logging block rule for all of IPv4 (or IPv6) that would match all protocols and thus would log TCP/UDP/IGMP/everything…?
Or is it really unexplained logged IGMP traffic?

what password are you changing?

@ermal:

32 bit builds are fixed as well now.

Confirmed good - I am now running on 32-bit Alix:
2.2.3-DEVELOPMENT (i386)
built on Wed Jun 10 10:48:12 CDT 2015
FreeBSD 10.1-RELEASE-p11