2.1.1-PRERELEASE Snapshots Available

ccb056

@ccb056:

Does it fix this issue:

https://redmine.pfsense.org/issues/3321

I'm not sure anything has changed there, but it's worth testing and updating the ticket with your results.

Just upgraded and ran a test.

After rebooting the modem, my IPSEC tunnels now come back online. Problem Solved! :)

wladikz

Hello,

Anyone has chance to test ixgbe drivers? my 2 firewalls are in production and i can't use it for test :(

doktornotor

@jimp:

Update URLs for use in firmware update settings:
http://snapshots.pfsense.org/FreeBSD_RELENG_8_3/amd64/pfSense_RELENG_2_1/.updaters/
http://snapshots.pfsense.org/FreeBSD_RELENG_8_3/i386/pfSense_RELENG_2_1/.updaters/

Hmmm… Not really working for me.

Unable to check for updates.
Could not contact custom update server.

fragged

The snapshot server is down right now.

wladikz

@fragged:

The snapshot server is down right now.

Any Estimations when snapshot server will back online?

Criggie

@wladikz:

@fragged:

The snapshot server is down right now.

Any Estimations when snapshot server will back online?

The snapshots server is not responding to port 80 requests via IPv4, however it does reply to ping.

If I connect to the webserver by IPv6 it responds, but shows a set of files from 2011.

pfSense-2.0-RC1-4g-i386-nanobsd_vga.full.img.gz 2011-Mar-30 01:14:14 130.1M
pfSense-2.0-RC1-4g-i386-nanobsd_vga.upgrade.img.gz 2011-Mar-30 01:24:35 65.0M

I'm sure IPv6 isn't that lagged!

$ ping snapshots.pfsense.org
PING snapshots.pfsense.org (66.111.2.168) 56(84) bytes of data.
64 bytes from 66.111.2.168.static.nyinternet.net (66.111.2.168): icmp_seq=1 ttl=46 time=212 ms
64 bytes from 66.111.2.168.static.nyinternet.net (66.111.2.168): icmp_seq=2 ttl=46 time=214 ms
^C
–- snapshots.pfsense.org ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 212.237/213.517/214.798/1.361 ms

$ ping6 snapshots.pfsense.org
PING snapshots.pfsense.org(2610:1c0:1:25::51) 56 data bytes
64 bytes from 2610:1c0:1:25::51: icmp_seq=1 ttl=46 time=217 ms
64 bytes from 2610:1c0:1:25::51: icmp_seq=2 ttl=46 time=217 ms
^C
--- snapshots.pfsense.org ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 217.560/217.773/217.987/0.513 ms

doktornotor

Well yeah the URLs are 404, I cannot see the server being actually down.

jimp

Try again now.

doktornotor

@jimp:

Try again now.

Thanks, works now. 8)

Still having issues with http://files.pfsense.org/lists/fullbogons-ipv4.txt and http://files.pfsense.org/lists/fullbogons-ipv6.txt though, getting a timeout.

doktornotor

Well, I think it is still somehow broken…


Current version: 2.1.1-PRERELEASE
  NanoBSD Size : 2g
       Built On: Fri Jan 17 15:24:41 EST 2014
    New version: Sun Jan 19 02:56:26 EST 2014

  Update source: http://snapshots.pfsense.org/FreeBSD_RELENG_8_3/i386/pfSense_RELENG_2_1/.updaters/

This Jan 19 update for nanobsd-2g is just not there, just the version file. It is not here either. Looks like none of the Jan 19 nano-bsd snapshots for i386 got uploaded; amd64 looks OK.

maverick_slo

Yup it does not work…
I just did upgrade and I still have update available warning on frontpage...

phil.davis

There are 20-Jan snapshots there now. The snapshot builder will run again every 8 hours or so if it finds any changes in GitHub (and I think it runs every 24 hours or so even if nothing seems to have changed?). So there will be times when you update, then 5 minutes later a new snapshot build happens to finish and so it tells you there is another update available.

maverick_slo

Nope, that was not the case.
I upgraded to snapshot lets say "1005" and it reminded me that upgrade to version "1005" is available.
I understand build process fairly good I would say :)

jasonlitka

I just upgraded the backup of my CARP pair as a test because I've had more than a few issues with the 2.3.1 version of the igb driver.

No issues on the first boot, but I'm disappointed to see that the newer igb driver (2.4.0) was included even though it still breaks altq. I assumed that since no mention of that issue was included in the notes that the team had come up with a workaround. Guess I was wrong.

EDIT: On the plus side though, I no longer have to disable MSI-X and I can now enable multiple queues for igb. ~~Looks like I'll have a decision to make when 2.1.1 drops.~~ See below for a reply from jimp.

mastahfr

Any chance of the WAN DHCP client option to be put sometimes in the snapshots (Option 60, etc) ? I remember that a pull allowing to add option on dhcp client has been done a while ago on 2.2 (from memory).

jimp

@Jason:

I just upgraded the backup of my CARP pair as a test because I've had more than a few issues with the 2.3.1 version of the igb driver.

No issues on the first boot, but I'm disappointed to see that the newer igb driver (2.4.0) was included even though it still breaks altq. I assumed that since no mention of that issue was included in the notes that the team had come up with a workaround. Guess I was wrong.

EDIT: On the plus side though, I no longer have to disable MSI-X and I can now enable multiple queues for igb. Looks like I'll have a decision to make when 2.1.1 drops.

That was unintentional, there was supposed to be a legacy TX option that was set to allow ALTQ to function on the new driver.

jimp

@mastahfr:

Any chance of the WAN DHCP client option to be put sometimes in the snapshots (Option 60, etc) ? I remember that a pull allowing to add option on dhcp client has been done a while ago on 2.2 (from memory).

Unlikely, this is focusing on bug fixes and not features.

jasonlitka

@jimp:

@Jason:

I just upgraded the backup of my CARP pair as a test because I've had more than a few issues with the 2.3.1 version of the igb driver.

No issues on the first boot, but I'm disappointed to see that the newer igb driver (2.4.0) was included even though it still breaks altq. I assumed that since no mention of that issue was included in the notes that the team had come up with a workaround. Guess I was wrong.

EDIT: On the plus side though, I no longer have to disable MSI-X and I can now enable multiple queues for igb. Looks like I'll have a decision to make when 2.1.1 drops.

That was unintentional, there was supposed to be a legacy TX option that was set to allow ALTQ to function on the new driver.

That sounds suspiciously like the patch I found and added to the ticket I have open with support. Excellent, thanks.

afrugone

Hi,

This version will fix the problem with multiwanand squid?

Thanks for your comments

charliem

@jimp:

Unlikely, this is focusing on bug fixes and not features.

Any chance of a fix going in for the failure to reset states after a WAN reset? The fix put in https://redmine.pfsense.org/issues/1629 did not work for me and at least a few others.

I fixed mine locally as described here: https://forum.pfsense.org/index.php/topic,70418.msg385188.html#msg385188, lots more info in the whole thread.