Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

interfaces: avoid long names with stacked _wlan, _vlan, _stf, ... #3222

Open
thomasjsn opened this issue Feb 11, 2019 · 18 comments

Comments

@thomasjsn
Copy link
Contributor

commented Feb 11, 2019

I've tried to upgrade from 18.7.10, and to live-boot 19.1 and 19.1.1. When I do I loose all internet access; both IPv4 and 6 on all connected devices.

Using the ping diagnostics from OPNsense itself I can see that IPv4 connectivity works, but IPv6 fails. During boot the following message is listed twice "Configuring firewall...failed".

I get a few notifications regarding too long interface name;
2019-02-11-221810_1428x208_scrot

Looking in the log I found this, it seems to indicate that the interface using VLAN for my WAN does not exist.
2019-02-11-221957_1386x241_scrot

I dont recognize the literal name igb0_vlan102_stf, but both the VLAN and interface does exist.
2019-02-11-222114_1245x347_scrot
2019-02-11-222140_1328x461_scrot

Have some internal names changed from 18.7 to 19.1? It does look like the name of the interface is igb0_vlan102. Without the _stf suffix.
2019-02-11-222344_784x647_scrot

What is happening? Any more information I can provide?

@AdSchellevis

This comment has been minimized.

Copy link
Member

commented Feb 12, 2019

_stf suggests a 6rd or 6to4 network, we changed something in the naming, to use the technical name instead of the logical one, which seems to be 1 character longer.

I think you should be able to revert this change adf314a, but we have to think of a better solution to prevent an overrun in this case.

@AdSchellevis AdSchellevis self-assigned this Feb 12, 2019

@AdSchellevis AdSchellevis added the bug label Feb 12, 2019

@fichtner

This comment has been minimized.

Copy link
Member

commented Feb 12, 2019

@AdSchellevis

This comment has been minimized.

Copy link
Member

commented Feb 12, 2019

@fichtner I'll take a look

@AdSchellevis

This comment has been minimized.

Copy link
Member

commented Feb 12, 2019

Changing the vlan naming scheme is a bit too tricky in the short term, since these are stored and there's more logic tied to it (if we change it, already configured devices will still use the previous name).

Most of the times the length doesn't lead to issues, it's probably a better idea to fix the _stf part for now.
How about if we suffix the stf interface with a capital S, which would create an interface like igb0_vlan102S.

It should be easy to test, low impact for as far as I can see.

@fichtner

This comment has been minimized.

Copy link
Member

commented Feb 12, 2019

In this case let me rather add a compatibility layer with the old naming scheme?

@AdSchellevis

This comment has been minimized.

Copy link
Member

commented Feb 12, 2019

and leave the _stf? we could do both, rename _stf now, keep the issue open for a larger overhaul.

@fichtner

This comment has been minimized.

Copy link
Member

commented Feb 12, 2019

Hmm, I'm not sure diverting from _wlan _vlan _stf scheme is of any benefit if we have a "better" and also confirmed working versions which is the old one from pre-19.1. I agree with the larger cleanup.

We also need a 19.1.x target that reboots so that no intermittent upgrade issues exist so I'll do a clean revert into a working version. I just don't want to break things even if it looks easy.

@fichtner fichtner self-assigned this Feb 12, 2019

@fichtner fichtner added this to the 19.7 milestone Feb 12, 2019

@AdSchellevis

This comment has been minimized.

Copy link
Member

commented Feb 13, 2019

I'll leave this up to you then, reverting back to the previous naming scheme is fine for the short term too.

@thomasjsn

This comment has been minimized.

Copy link
Contributor Author

commented Feb 14, 2019

I do have 6rd set up on that interface, so that makes sense. I was also seeing IPv6 related error messages in the log.

@fichtner That does this mean for my set up? Is there anything I can do to get 19.1 working? Or do I have to wait for a fix?

@AdSchellevis

This comment has been minimized.

Copy link
Member

commented Feb 14, 2019

@thomasjsn I'll prepare a temporary fix for you, @fichtner can look at the final solution later

@AdSchellevis

This comment has been minimized.

Copy link
Member

commented Feb 14, 2019

here you are, should revert the behaviour back to 18.7

 opnsense-patch 2eabec27
@thomasjsn

This comment has been minimized.

Copy link
Contributor Author

commented Feb 14, 2019

@AdSchellevis Thanks, so; Install 19.1, upgrade to 19.1.1 and apply patch?

@AdSchellevis

This comment has been minimized.

Copy link
Member

commented Feb 14, 2019

I expect you can apply on both versions, so if you need the connectivity, first patch 19.1, then upgrade and apply again.

@fichtner

This comment has been minimized.

Copy link
Member

commented Feb 14, 2019

@AdSchellevis thank you, I'm going to add it to 19.1.2 as well.

@thomasjsn feedback about patch making things work again is appreciated so we can safely go ahead and fix the underlying issue(s) later.

fichtner added a commit that referenced this issue Feb 14, 2019
@thomasjsn

This comment has been minimized.

Copy link
Contributor Author

commented Feb 14, 2019

This is what I did:

  • Booted of 19.1 USB stick into liveCD mode.
  • Updated to 19.1.1.
  • SSHed into OPNsense and ran the command opnsense-patch 2eabec27.
  • Restarted service pf from dashboard, IPv4 connectivity came back on all network devices, still no IPv6.
  • Went to Interfaces -> WAN, clicked "Save" and "Apply", IPv6 connectivity came back on all network devices.

I'd say it looks like the patch works :)

@AdSchellevis

This comment has been minimized.

Copy link
Member

commented Feb 15, 2019

@thomasjsn thanks for confirming, I'll leave the rest up to @fichtner

@fichtner

This comment has been minimized.

Copy link
Member

commented Feb 15, 2019

Already queued up for 19.1.2, thanks!

@fichtner fichtner changed the title Configuring firewall fails during boot after upgrade to 19.1 interfaces: avoid long names with stacked _wlan, _vlan, _stf, ... Feb 15, 2019

@fichtner

This comment has been minimized.

Copy link
Member

commented Feb 18, 2019

Same as
#3120

@fichtner fichtner added this to To Do in 20.1 Jul 18, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
3 participants
You can’t perform that action at this time.