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)

Submitted by:  Simon Goldschmidt <goldsimon>
Submitted on:  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
Percent Complete:  100% Assigned to:  Simon Goldschmidt <goldsimon>
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>
Project AdministratorIn charge of this item.
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>
Project AdministratorIn charge of this item.
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>
Project AdministratorIn charge of this item.
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>
Project 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>
Project AdministratorIn charge of this item.
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>
Project AdministratorIn charge of this item.

 

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)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

     

     

    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


    Powered by Savane 3.5