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.osdl.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. ------_=_NextPart_001_01C48167.7E2F3D60 éeI 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? u© [...] 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
