tasklwIP - A Lightweight TCP/IP stack - Tasks: task #9033, Support IEEE 802.1q tagged frame...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

task #9033: Support IEEE 802.1q tagged frame (VLAN)

Submitter:  Simon Goldschmidt <goldsimon>
Submitted:  Wed 21 Jan 2009 03:16:49 PM UTC
   
 
Category:  ARP Should Start On:  Wed 21 Jan 2009 12:00:00 AM UTC
Should be Finished on:  Wed 21 Jan 2009 12:00:00 AM UTC Priority:  5 - Normal
Status:  Done Privacy:  Public
Assigned to:  goldsimon Percent Complete:  100%
Open/Closed:  Closed Planned Release:  1.4.0
Effort:  0.00

Tue 25 Aug 2009 03:30:10 PM UTC, comment #5: 

Checked in the patch from comment #1 with some additions in ethernet_input().

Please reopen if it's not OK - especially the changed structs, which should not make any problems, I guess.

 Simon Goldschmidt <goldsimon>
Group administrator
Thu 07 May 2009 04:10:59 PM UTC, comment #4: 

I've had a look through our stack needing the VLAN tag support: only RX is needed, I'd not implement TX right now (don't know if it's needed). Since RX only involves splitting the header structs, I'd still target that at 1.3.1.

With that, even nested VLAN headers (are they allowed?) wouldn't be a problem.

I'd only enable this with an option (maybe a flag in the netif) to prevent receiving all VLAN traffic (or only if you want it). Checking the VLAN can be implemented easily, too, but I don't know if that's needed (at least not for me, right now).

 Simon Goldschmidt <goldsimon>
Group administrator
Sat 14 Feb 2009 01:14:22 PM UTC, comment #3: 


> I'm not so sure: is it right to accept packets for a VLAN that
> you have not been configured to be part of? If it is, that's
> fine, I'm just not sure what the correct behaviour is.


As far as I know (and have been using it), there are three possibilities:

a) your device gets all traffic
b) your device only gets traffic for the VLAN it is configured for
b1) including VLAN header
b2) VLAN header is stripped of by the switch

In case a), it is of course not correct to accept packets for the wrong VLAN. However in case b1), it is. Case b2) already works since it is no difference from a normal LAN. Maybe we should add a check for a configured VLAN?

> The other problem I can see is that we won't deal with nested
> VLAN packets very well - it assumes that the IP hdr follows a
> single VLAN tag.


Is that allowd? I didn't know that. I though whoever addes a VLAN header has to replace an existing one: otherwise you can't guarantee a maximum packet length in your network... I'll try to check what the RFC says about that.

 Simon Goldschmidt <goldsimon>
Group administrator
Fri 13 Feb 2009 09:43:18 AM UTC, comment #2: 

I'm not so sure: is it right to accept packets for a VLAN that you have not been configured to be part of?  If it is, that's fine, I'm just not sure what the correct behaviour is.

The other problem I can see is that we won't deal with nested VLAN packets very well - it assumes that the IP hdr follows a single VLAN tag.

 Kieran Mansley <kieranm>
Group Member
Thu 12 Feb 2009 08:31:14 PM UTC, comment #1: 

Does anyone have something against the attached patch? If not, I'll check it in ;-)

(I've mainly splitted the structs eth_hdr and etharp_hdr and point etharp_hdr to the correct location depending on whether there is a VLAN part or not.)

Code size should not differ that much, a few bytes at maximum.

(file #17443)

 Simon Goldschmidt <goldsimon>
Group administrator
Wed 21 Jan 2009 03:16:49 PM UTC, original submission:  

The receive part should be relatively easy: just accept all frames whether VLAN tagged or normal (therefore marked as planned for 1.3.1).

The transmit side could be a compile time option or a runtime option per netif...

Any preferences?

 Simon Goldschmidt <goldsimon>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attached Files
file #17443:  etharp_vlan.patch added by goldsimon (9KiB - text/x-patch)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by kieranm (Posted a comment)
  • -email is unavailable- added by goldsimon (Submitted the item)

    •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2009-08-25 goldsimon StatusNone Done
        Percent Complete0% 100%
        Assigned toNone goldsimon
        Open/ClosedOpen Closed
    2009-04-03 kieranm Planned Release1.3.1 1.4.0
    2009-02-12 goldsimon Attached File- Added etharp_vlan.patch, #17443

    Back to the top

    Copyright © 2024 Free Software Foundation, Inc.
    Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
    The Levitating, Meditating, Flute-playing Gnu logo is a GNU GPL'ed image provided by the Nevrax Design Team.
    Page source code

    Powered by Savane 3.13-7a7b.
    Corresponding source code