Single-port VLAN tagging device?

Hi guys, I was just interested whether you know of a device that could look e.g. like a standard RJ45 female-female extension, but would add a predefined VLAN tag in one direction.

I have an unmanaged switch with 802.1Q support, and because of space and temperature constraints (it has to be inside a robot body), I cannot afford putting there some normal managed switch. And industrial-grade managed switches are too bulky (if you know of a small 5+ port managed switch which can operate reliably in 65°C, let me know).

Now, I’d like to add a VLAN tag to one device’s output. My idea was that it should be a pretty simple operation (adding a few bytes before and after each packet). And thus I’d expect there could be a small device out there doing just this. But my google-fu was unsuccessful…

Thanks for any tips

What is your definition of small?

112.2 x 29.1 x 89.4 mm ( is what we have there now, even with this we had problems with space… especially the thickness can’t be any higher…

One could infer from it but still does not say what are the exact dimensional constrains.

Did you see

Product Dimensions 107x102x28 mm, 4.2x4.0x1.1 inches

That one’s unmanaged, too…

If you do not require a casing perhaps embeddable boards are the way to go

• Length (L): 3.775 inches (95.89 mm)
• Width (W): 3.550 inches (90.17 mm)
• Stand-off Height: 0.600 inches (15.24 mm)

Or one of those

1 Like

These look nice… But the price… Well above $1000… :frowning:

Well, can only do so much to meet

  • dimensional constraints
  • environmental constraints
  • management feature

but cannot help with funds… But perhaps searches in that direction may yield something more affordable., managed switch, 5 ports, -20°C to 70°C. Around 40€.

1 Like

Nice, but I’m afraid it is too big… but we might buy one just for testing if it doesn’t fit in…

why dont you tag vlan on managed switch placed somewhere else and located between device and router?

Why dont you use some RPI with with 2gbe ports? or similar device?

There are multiple dumb sensors and other devices on the robot which do not support VLAN tagging. And because of spatial constraints, adding another switch is not possible. We can either exchange the current one, ore put there some miniature “VLAN tagger” devices.

With the raspberry pi, I was thinking about some similar solution, but much smaller. Even the size (footprint) of Raspi zero seems as an overkill to me for a pure “VLAN tagger”. And I wouldn’t trust a raspi running in 65°C ambient… The whole robot is only cooled by dissipation via a 0.25 m2 aluminium plate, so airflow doesn’t help much (there is a CPU fan running inside the body, but it only circulates air in the closed body).

I’ve done some more research about the D-Link switch we have. It contains switch chip Qualcomm QCA8337N-AL3B. In the docs for the chip, it is said that it supports port-based VLAN tagging. So it seems the problem is only that the switch manufacturer did not make the management API available.

However, further in the docs, I’ve found this section:

Atheros header
The QCA8337N support proprietary Qualcomm Atheros header that can indicate the packet
information and allow CPU to control the packet forwarding. The header can be 2 bytes or 4 bytes
with additional 2 bytes identifier. For 2 bytes header, each packet sent out or received must include
header. For 4 bytes header, header can exist only in the management frame and there is no header
in the normal frame. The Atheros header also supports read/write register through the CPU port

So it seems that it could be possible to send some special hand-crafted Ethernet frames to the switch which would set up e.g. the port-based tagging. The docs say these frames can read and modify many config registers in the chip, and there seem to be registers setting up the port-based VLAN tagging. Does anybody have any experience with that? Are there any libraries/programs that would help me?

And why would the manufacturer tell it is an unmanaged switch if it were sufficient to provide some configuration software and he could sell it as a managed switch?

Silly idea (expanding on @anon50890781 proposal), just take the smallest managed switch you can find and just extract and mount the PCB, that should reduce the size envelope and might even allow better convection-based cooling?

1 Like

Hi. If you are a tinkerer, check this article describing how to convert cheap unmanaged switch to managed.

I’ve stumbled upon exactly this article. However, there are no docs for the switch we have that would tell me where the MDI interface pins are. There are three headers with bare pins on the board, but as there are no docs, I’d be afraid connecting anything to them… I’ve contacted the manufacturer, let’s see if he’ll tell me what the pins are for.

This is why I’d rather go the custom Ethernet frames way…

You have stated that your switch is based on QCA8337N. Have you tried to find the datasheet?
I’m reading it and see that MDIO pins are A53 and B45.
UART_RXD/MDC - Management data clock ref.
UART_TXD/MDIO - Management data.
You can try to trace the PCB trace to the pin header.

Look for register settings how to properly configure the VLAN tagging.

My guess is, that the specs for the Qualcom Atheros management headers are available only when you sign the NDA.

Anyway, good luck!

Yeah, that’s basically what I’d want to do, but the PCB is multilayer and the chip pins are super tiny :frowning: I’ll wait if the Taiwanese respond me about the headers and what do they provide on them… If they won’t respond, then I’ll try to treat the 4-pin header as a UART or MDC connector (but I don’t even know the voltage, though 3.3 V seems appropriate to me)…

Check the table 4.1 Absolute maximum ratings.
Btw, check also the 3.6 section, it is a description of the management headers, that is exactly what you need.


Well, these are the maximum ratings for known desired voltages. But I couldn’t find the desired voltage for the MDI bus…

And management headers are the thing I was writing about. It’s just so that I’ve never worked with Ethernet frames directly, and I hoped someone will know about a library that would make this work (much) easier…