Skipped content of type multipart/alternative-------------- next part
--------------
A non-text attachment was scrubbed...
Name: Glacier Bkgrd.jpg
Type: image/jpeg
Size: 2743 bytes
Desc: not available
Url :
http://lists.linux-foundation.org/pipermail/bridge/attachments/20040813/40d97dc7/GlacierBkgrd.jpg
-------------- next part --------------
Spam detection software, running on the system "fire-1.osdl.org", has
identified this incoming email as possible spam. The original message
has been attached to this so you can view it (if it isn't spam) or block
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: This message is in MIME format. Since your mail reader
does not understand this format, some or all of this message may not be
legible. ------_=3D_NextPart_001_01C48167.7E2F3D60 =1D=E9eI am trying to
understand how the bridge code deals with the Ethernet FCS. I have
written a WLAN driver, and have tied it to eth0 via the bridge
utilities. What confuses me is that when my hard_start_xmit routine is
called, when it is receiving data from eth0, it comes complete with the
FCS. For a typical max length TCP packet, this puts the total frame
length at 1504, which exceeds the 1500 Ethernet MTU. So if my an
unknowing driver takes the full payload and sends it across the
wireless link, where on the other side it is passed back to Ethernet
(also via the bridge code), it is discarded since 1504 > MTU. How is
this situation typically dealt with? L=80=00u=A9 [...]
Content analysis details: (6.7 points, 5.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
1.1 MIME_BASE64_LATIN RAW: Latin alphabet text using base64 encoding
1.1 MIME_BASE64_TEXT RAW: Message text disguised using base64 encoding
0.2 MIME_BASE64_NO_NAME RAW: base64 attachment does not have a file name
4.3 FORGED_IMS_TAGS IMS mailers can't send HTML in this format
