I'm thinking in context that the 802.1q support a switch provides is fully sufficient for our use--it's a formal standard and bar for the vendor to meet. I'm not aware of a driver to want to hack a switch that already supports 802.1q. I suspect no one has yet had an interest/need go un-meet that would cause the firmware to be hacked. It has really become a 'commodity'.
Now that would be a need to hack the switch and change any hardcoded internal use of vlan1 to another tag--I recall now this was in a prior forum discussion somewhere--"can not" use vlan1 on this particular model.
An alternative option would be to edit the related file(s) under /etc and change the node's usage of vlan1 to another tag #. ...tyical disclaimer of risk of heart burn, elevated heart rate, loss of life, non-support, blowing up your barn, etc., did I mention no guarantees :) . Just change the reference in /etc/config/network from "eth0.1" to something like "eth0.3" (for vlan3) on a ubnt node (more steps if the node has a built in switch on some 2-port devices).
Other references and dependencies in the config files (firewall, olsr, hotplug, etc.) use the notation/alias "wan" and continue to work correctly. Now configure your 802.1q switch for the node's wan to be vlan3. Note, vlan3 might be used for a future feature, so there's probably a better tag to use. Best to also do this in /etc/config.mesh/network to preseve across setup 'save's. You may need to reapply this change across package installs and future upgrades. (now what other dependencies didn't I think of beyond this 1 character change...)
[follow up edit] I found one additional dependency in the initial status page of the node. There's a couple lines of perl code to update to correctly show status of the wan--which I made on my node. Let's connect up directly if this is something you're intereseted in persuing. We're getting into linux under the hood stuff and straying from the released images--not something everyone should venture forward with without some prior familiarity with perl and linux.
Here is the content of my NSM2 /etc/config/network file ..
I understand that I need to change the wan VLAN to something other than 1 ... I will do 9
but what about the switch part?
My $0.02 worth....
this definitely is a protocol breaker and I would not advise doing it. when in an EMCOMM situation, these are things that can be easily forgotten when you have a non-compliance/standard node and may be asked to provide mesh to other areas/nodes.
Aly,
There is no need for your application to go non-standard. There are configuration notes elsewhere on this site with several good options. I can help you with what Dave, N3UXK and I use around here for EMCOMM. We usually set up port 8 for Internet gateways, and ports 1, 4 and 6 for dtd using VLANs 10, 20 and 30 respectively. We then point ports 2 and 3 to port 1, 5 to 4 and 7 to 6. We then break out those ports using non-VLAN switches if we need to support more devices. We can always chop VLAN 30 out and put ports 6 and on 10 and could do them same for VLAN 20 and put ports 4 and 5 VLAN 10 if we need the ports on a common VLAN.
All my packaged EMCOMM nodes W2TTT-[HOME|MOBILE|FIELD|PORTABLE]-AG5 are old M5 Airgrids without reflectors on a low channel so they will mesh when they physically converge despite whatever else they might have at that time in their respective packages. This allows for ease of configuration on the bench or in the field. These nodes are also sources of stable IP addresses for their respective packages. Each has an identical Netgear VLAN switch and a non-VLAN switch for port expansion as needed. Everything is wired tbrough a PowerPole buss running between 12-15VDC.
Makes life simpler for EMCOMM to set things up this way.
Hope this helps!
73,
Gordon Beattie, W2TTT
201.314.6964
Leave the node with its normal setting intact. Do not set a manual IP address. When the node is connected to the switch, and a cable from port 8 on the switch connects to a port on your ISP router, the node will automatically get a gateway IP address (which is your ISP router) and be able to see the Internet.
No, Port 1 and all the other ports associated with VLAN 10 should be Untagged, per all of the example switch configurations posted on this site.
Port 1 is Tagged only on VLAN 1 to provide access to the WAN on port 8.
Old post, however worth noting that there is a "new" answer: it depends -- on the "hardware version" of the switch!
It appears that this is no longer a problem with the brand new hardware version (v4) ... and there is a new firmware version from TP-LINK for hardware version 3 (the version which Amazon has been unloading on super special recently) for both the 105 and the 108 switches which allows changing the the VLAN configuration to allow mesh WAN to work, etc:
Here's the details for the 108/v3 from: https://www.tp-link.com/us/download/TL-SG108E_V3.html#Firmware
Published Date: 2018-01-05 name: TL-SG108E(UN)_V3_20171214
"New Features/Enhancement:
1.The port can be removed from VLAN1
2.The port of VLAN1 can choose tagged/untagged"
I can confirm Don's note on on the Version 3 TP-Link switch. I have several of them and they work just fine as a VLAN switch, similar to the Netgear switches.
No 3rd party firmwares exist to my knowledge, at least not in the normal tree lines I work on (OpenWRT and DDWRT)
Switches don't tend to be high on the 3rd party hardware 'hacking' list.
I'm thinking in context that the 802.1q support a switch provides is fully sufficient for our use--it's a formal standard and bar for the vendor to meet. I'm not aware of a driver to want to hack a switch that already supports 802.1q. I suspect no one has yet had an interest/need go un-meet that would cause the firmware to be hacked. It has really become a 'commodity'.
great little switch, the problem is you can edit vlan 1. so you can DtD but not tunnel, unless I missed something in the how to.
Now that would be a need to hack the switch and change any hardcoded internal use of vlan1 to another tag--I recall now this was in a prior forum discussion somewhere--"can not" use vlan1 on this particular model.
An alternative option would be to edit the related file(s) under /etc and change the node's usage of vlan1 to another tag #. ...tyical disclaimer of risk of heart burn, elevated heart rate, loss of life, non-support, blowing up your barn, etc., did I mention no guarantees :) . Just change the reference in /etc/config/network from "eth0.1" to something like "eth0.3" (for vlan3) on a ubnt node (more steps if the node has a built in switch on some 2-port devices).
Other references and dependencies in the config files (firewall, olsr, hotplug, etc.) use the notation/alias "wan" and continue to work correctly. Now configure your 802.1q switch for the node's wan to be vlan3. Note, vlan3 might be used for a future feature, so there's probably a better tag to use. Best to also do this in /etc/config.mesh/network to preseve across setup 'save's. You may need to reapply this change across package installs and future upgrades. (now what other dependencies didn't I think of beyond this 1 character change...)
[follow up edit] I found one additional dependency in the initial status page of the node. There's a couple lines of perl code to update to correctly show status of the wan--which I made on my node. Let's connect up directly if this is something you're intereseted in persuing. We're getting into linux under the hood stuff and straying from the released images--not something everyone should venture forward with without some prior familiarity with perl and linux.
Joe AE6XE
Hello, Joe ...
Here is the content of my NSM2 /etc/config/network file ..
I understand that I need to change the wan VLAN to something other than 1 ... I will do 9
but what about the switch part?
this definitely is a protocol breaker and I would not advise doing it. when in an EMCOMM situation, these are things that can be easily forgotten when you have a non-compliance/standard node and may be asked to provide mesh to other areas/nodes.
Aly,
There is no need for your application to go non-standard. There are configuration notes elsewhere on this site with several good options. I can help you with what Dave, N3UXK and I use around here for EMCOMM. We usually set up port 8 for Internet gateways, and ports 1, 4 and 6 for dtd using VLANs 10, 20 and 30 respectively. We then point ports 2 and 3 to port 1, 5 to 4 and 7 to 6. We then break out those ports using non-VLAN switches if we need to support more devices. We can always chop VLAN 30 out and put ports 6 and on 10 and could do them same for VLAN 20 and put ports 4 and 5 VLAN 10 if we need the ports on a common VLAN.
All my packaged EMCOMM nodes W2TTT-[HOME|MOBILE|FIELD|PORTABLE]-AG5 are old M5 Airgrids without reflectors on a low channel so they will mesh when they physically converge despite whatever else they might have at that time in their respective packages. This allows for ease of configuration on the bench or in the field. These nodes are also sources of stable IP addresses for their respective packages. Each has an identical Netgear VLAN switch and a non-VLAN switch for port expansion as needed. Everything is wired tbrough a PowerPole buss running between 12-15VDC.
Makes life simpler for EMCOMM to set things up this way.
Hope this helps!
73,
Gordon Beattie, W2TTT
201.314.6964
Gordon,
I really appreciate your help.
I opted for using a NETGEAR GS108Ev3 smart managed switch.
Everything is up and running except the node can't connect to the WAN network.
PORT 1: Node
PORT 2-7: LAN
PORT 8: WAN
The LAN seems to be working just fine.
The node doesn't connect to wan. even when I set a static IP (in the range of the wan DHCP) it doesn't ping the wan or vice versa.
You help will be much appreciated.
Port 1, VLAN 10 needs to be tagged.
Based on what I have set up and sent to you directly, that's standing out as a difference
Port 1 is Tagged only on VLAN 1 to provide access to the WAN on port 8.
Old post, however worth noting that there is a "new" answer: it depends -- on the "hardware version" of the switch!
It appears that this is no longer a problem with the brand new hardware version (v4) ... and there is a new firmware version from TP-LINK for hardware version 3 (the version which Amazon has been unloading on super special recently) for both the 105 and the 108 switches which allows changing the the VLAN configuration to allow mesh WAN to work, etc:
Here's the details for the 108/v3 from:
https://www.tp-link.com/us/download/TL-SG108E_V3.html#Firmware
Published Date: 2018-01-05 name: TL-SG108E(UN)_V3_20171214
"New Features/Enhancement:
1.The port can be removed from VLAN1
2.The port of VLAN1 can choose tagged/untagged"
HTH,
- Don - AA7AU