0

My computer is connected to another computer via Ethernet (via a very simple unmanaged switch). I want to make the traffic between the two computers VLAN tagged with 802.1q protocol. My computer use Intel l1219-LM Ethernet network adapter.

  1. I used this reference to make sure I will be able to see the vlan tags while using Wireshark.
  2. As recommended here I updated my Intel network adapter driver so it will support VLANs over Windows 10.
  3. I have created a VLAN in both computers, with the VLAN tag 5.

Now- when sniffing the traffic with Wireshark I can see 3 types of packets:

  1. Packets without any VLAN tagging, (that are sent from my computer, I assume it is OK)

  2. Packets with VLAN tags using 802.1q protocol-

  3. Packets with VLAN tags using ISL protocol- In those, the the Ethernet part is considered malformed because the Ethernet CRC is zeros.

(I wanted to upload images to make it more clear, but unfortunately I can't because of low reputation)

When I run a client-server application between the two computer, the other side's packets are received in the computer (can be seen in Wireshark), but not in the application. Those packets are sent only over the ISL protocol.

So my problems are-

  1. Why are the packets not received? Is it because of the malformed Ethernet CRC?
  2. How do I cause my computer to send the packets only in 802.1q protocol, rather than ISL?

And most of all-

  1. What is going on here?? Why does the Intel network adapter use a Cisco proprietary protocol for connection between switches? It doesn't make any sense to me...

Thank you very much, any help would be appreciated!

Edit:

I realized that I hadn't really explained what I'm trying to do, maybe it will help. I'm a security researcher, and I am trying to investigate the option to inject packets of a certain application (the client-server app I have mentioned) into an existing VLAN traffic on an existing system. In order to do that- I need the packets that are getting out of my NIC to be already VLAN tagged with the right tag. In addition, I need the other side to not ignore them because of the zeros FCS.

I don't really care about the switch between the computers (it is only there to connect the two computers...), and I'm very aware to the fact that this is not a good practice of doing things. My purpose is not to build a network, but only to test one.

Update

I removed the switch and connected the two computers directly, and the problem is still happening (I think I see only ISL this time, and not 802.1q at all). So that means the ISL is generated by my NIC, and not by the switch.

Also- I do believe I see ISL, and not some garbage, because the VLAN ID in the header is the VLAN tag that I have defined.

Any ideas?

Thanks

Shir
  • 111
  • 1
  • 6
  • Do you have the VLAN configured on the switch interfaces? – Ron Maupin Dec 01 '17 at 21:47
  • Along the lines of Ron's question, you don't mention the vendor/model of the switch, nor how it is configured. You would want to set up a tagged link between your computer(s) and the switch. If the switch isn't also aware of the VLANs you are using, there won't be any logical separation of traffic that VLANs provide and are prone to all sorts of issues (if it even works at all). – YLearn Dec 02 '17 at 03:41
  • I'm using TP SF1005D switch. This is an unmanaged switch, so I assumed it just ignores the vlan tags and pass all packets to all relevant ports (without changing the tagging protocol for example). But- my goal here is to cause the packets leaving my computer to be VLAN tagged with 802.1q protocol, the switch is actually just part of the testing setup. – Shir Dec 02 '17 at 07:30
  • What an unmanaged switch does with tagged frames is undefined. some will simply pass the frames on, some will remove the tags, some will drop the frames as malformed, etc. To test what you are doing, you should directly connect the two PCs. – Ron Maupin Dec 02 '17 at 18:37
  • I don't think the frames are using ISL (a Cisco proprietary protocol). I think the switch is confused by the 802.1Q tags, and you are getting garbage that is being misinterpreted by the receiving host. It may be that the switch is removing the tags, which will throw off the the CRC, or the switch may be truncating the frames, which, again, will throw off the CRC. You really have no way to know ahead of time how a switch that doesn't understand 802.1Q tags will respond to receiving tagged frames. – Ron Maupin Dec 03 '17 at 01:08
  • Also, many enterprise-grade switches that do understand 802.1Q tags will drop tagged frames on an access interface as a security measure. This is to prevent VLAN hopping. – Ron Maupin Dec 03 '17 at 01:11
  • Please see my update- I have removed the switch and it didn't change it. Any more ideas? thanks – Shir Dec 03 '17 at 07:23
  • ISL doesn't use VLAN tags. It is has an outer header that encapsulates the original frame. 802.1Q inserts a four-byte tag in the ethernet header, but ISL does not. ISL creates a completely separate header, and it does not alter the original frame. ISL is a Cisco-proprietary protocol, and even Cisco equipment no longer uses it. – Ron Maupin Dec 03 '17 at 07:31
  • I meant to the VLAN ID field in the ISL header. I can send you a pcap file or upload a picture somehow if it would help. – Shir Dec 03 '17 at 07:43
  • What are the first six bytes of the frame header? – Ron Maupin Dec 03 '17 at 07:54
  • 0x01000c000000 (I have read it is normal in ISL) – Shir Dec 03 '17 at 07:57
  • I think you have some type of driver problem. Since this is not Cisco equipment, it should not be able to use ISL, which is Cisco-proprietary. – Ron Maupin Dec 03 '17 at 08:04
  • I have the latest driver from Intel's website, I don't think I have any other option :( – Shir Dec 03 '17 at 09:02

1 Answers1

0

Configuring VLANs without switch support - even if the frames are passed through - makes little sense. You normally use VLANs to separate traffic running on a single link. What are you trying to accomplish?

If you receive ISL tagged frames, these are from the other computer you haven't detailed. Both sides need to use compatible tagging unless the switch in between is able to translate/substitute the tags. Unknown tags, unknown VIDs etc. are dropped. Frames with invalid FCS are also dropped by the NIC (ie. not passed to the OS).

Zac67
  • 10,320
  • 2
  • 12
  • 32
  • On the first comment- please see my edit to the question, I tried to explain what I'm trying to do, hope it will help – Shir Dec 02 '17 at 18:17
  • On the second comment- you are right, I didn't mention that my test setup is symmetric. I have a similar computer in the other side (same NIC, same driver, same OS), and the problem is exactly the same there too (packets from my computer are received tagged by ISL and dropped). Regarding the FCS- it is not wrong, it's just always zeros. I thought that maybe the ISL implementation in the NIC driver (or wherever it is) might not include this mechanism, and will just ignore it for incoming packets (and therefor it will be marked wrong by Wireshark, but should be passed to the OS by the driver) – Shir Dec 02 '17 at 18:23
  • If you've just got the two computers, spare the switch - possibly it's acting up. – Zac67 Dec 02 '17 at 18:35
  • Please see my update- I have removed the switch and it's still ISL. Any more ideas? thanks! – Shir Dec 03 '17 at 07:25
  • 1
    I'm pretty sure an l1219-LM can't send ISL frames - can you post a capture? – Zac67 Dec 03 '17 at 14:58