Re: [Wireshark-dev] pcapng decoding error when preamble is shortened
> > It’s not a matter of *what* the program is reading, but *where* it's > > reading in the buffer. This makes it usable for *all* programs reading this > > file format, not just Wireshark. Prefixing it with zero padding (even a > > nibble) would achieve that. > As would changing the spec to indicate that the preamble may reflect the > length of the preamble as received, and thus that it's from 1 to 7 octets. Formally, 802.3br requires all receivers to accept arbitrary preamble length. I would argue that a dissector should aim to act like a receiver. No point in limiting it to 7 octets. > I infer from what Timmy Brolin, and from IEEE Std 802.3-2018, that there's no > guarantee that the receiver will see all the preamble bits sent by the MAC > layer, so I don't see this a indicating how long the packet was on the wire. > At least as I read section 22.2.3.2.2 "Receive case" of 802.3-2018, in the > clause talking about 100 Mbit Ethernet, all or none of the preamble may be > received over the MII - "Table 22–4 depicts the case where no preamble > nibbles are conveyed across the MII, and Table 22–5 depicts the case where > the entire preamble is conveyed across the MII." - (and I suspect any value > between "all" and "none" may be received). > At least as I read Figure 24-11 "Receive state diagram, part a", on the > wire/fibre, the preamble begins with two special 5-bit code-groups J and K, > in order, indicating the beginning of a bit stream. After that come more > 5-bit code-groups which encode the nibbles of the preamble, SFD, and data > (including the MAC header, payload, and FCS). I infer from that diagram that > the preamble isn't used for synchronization on the wire; it may be used for > synchronization between the MII and the PHY. It works a bit different for different Ethernet standards. * On 10Mbit Ethernet, the preamble IS used for synchronization on the wire. In this case, preamble bits can in some sense be "lost on the wire". Or the receiver needed an extra bit transition or two to sync up. * On 100Mbit Ethernet, the PCS replaces the first two nibbles of the preamble by J and K. Then on the receiving end it again replaces J and K by two preamble nibbles. * On Gigabit Ethernet there is a 16bit code group replacing the first bytes of preamble. In some sense similar to J and K, but 16bits long. > So it sounds as if a short preamble could be received because: > the transmitting station didn't send the entire preamble down its MII > (which means the transmitter is cheating, given that 22.2.3.2.1 "Transmit > case" says 7 octets are sent down the MII), and thus it wasn't put on the > wire after the J/K; There are specialized examples of where this is intentionally done to improve performance. The full 7 byte preamble is essentially wasted performance on 100Mbit and gigabit Ethernet. There are also cases where the implementation of the MAC layer cheats and drops some preamble to simplify its implementation. Not very common, but there are such implementations. > the transmitting station did send the entire preamble down its MII, but > the receiving station's Reconciliation Sublayer (RS) didn't manage to sync up > with its Physical Coding Sublayer (PCS) because it didn't sync up with the > PCS immediately - it needed to see a few bit transitions; This can happen on 10Mbit Ethernet. But it is also quite common for 100Mbit and Gigabit PHYs which chops off some preamble to save latency or simplify implementation. > the PCS Just Didn't Bother Sending The Full Preamble. Very common practice today, unfortunately. They do it to reduce latency or simplify implementation. > I don't think bits of the preamble would be lost *over the wire*, as I infer > that the receipt of the J/K starts the reception process, and if it's not in > sync with the transmitter at that point, no frame is going to be received. J/K only exists on 100Mbit Ethernet. 10Mbit Ethernet is different. You can also have network equipment on the wire which chops off some preamble. Can happen in some copper/fiber media converters for example. > I also *suspect* that "the PCS Just Didn't Bother Sending The Full Preamble" > isn't likely to be the cause of a short preamble. > A capture at the RS layer can't, as far as I know, distinguish between the > first two cases. Indeed. > The first case indicates that the transmitting station is trying to reduce > its use of network bandwidth and/or reduce the latency for the packet. > The second case indicates - something? > Other PHYs may behave differently. > The reasons for *not* padding a short preamble that I can see would be > 1) extra stuff for the receiver to do if it receives a short preamble; > 2) loss of an indication that the preamble is short - that indication > is presumably of interest to people reading the capture for purposes of > diagnosing low-level Ethernet issues (meaning "probably of interest to people
Re: [Wireshark-dev] [Season of Docs - Announcements] The 2021 Season of Docs application for organizations is open!
Hello, I don't see any mention to the doc/README.* files in this wiki, which are essential but sometimes a bit harsh. For example README.dissector is almost 4000 lines long without any Table of Content (but there's a numerotation for the paragraphs which could help building it), one doesn't always know how to deal with it. best regards E.A. Le ven. 19 févr. 2021 à 08:27, Alex Nik a écrit : > > Hi Moshe. > > I found some information for GSoD 2020 on the Wireshark wiki - there are more > ideas what to document on this page. It could be a good idea to apply for > GSoD 2021. > > Regards, > Alex > > On 11 Feb 2021, at 02:45, RAGE wrote: > > Hi Moshe. > > It is. For now I can see the wiki has outdated info or not has a description > at all for some technologies and tools the Wireshark project accumulates.. my > after project time I would still want to help with it's improvement if I can. > But if you want to become a participant of gsod either as an organization or > writer - go for it! It definitely worth it! <3 > I'm open to discuss the details in IRC or other communication channels. Feel > free to ping me. > > Regards, > > Alex > > > On Wed, Feb 10, 2021, 19:29 Moshe Kaplan wrote: >> >> Is this worth participating in again? >> >> Moshe >> >> -- Forwarded message - >> From: Season of Docs - Announce >> Date: Tue, Feb 9, 2021 at 1:09 PM >> Subject: [Season of Docs - Announcements] The 2021 Season of Docs >> application for organizations is open! >> To: Season of Docs - Announce >> >> >> We’re delighted to announce Season of Docs 2021! >> >> In 2021 the Season of Docs program will continue to support better >> documentation in open source and provide opportunities for skilled technical >> writers to gain open source experience. In addition, building on what we’ve >> learned from the successful 2019 and 2021 projects, we’re expanding our >> focus to include learning about effective metrics for evaluating open source >> documentation. >> >> What are the 2021 program changes? >> >> Season of Docs 2021 will allow open source organizations to apply for a >> grant, based on their documentation needs. If selected, open source >> organizations will use their grant to hire a technical writer directly to >> complete their documentation project. Organizations will have up to six >> months to complete their documentation project. Keep reading for more >> information about the organization application or visit the Season of Docs >> site. >> >> Technical writers interested in working with accepted open source >> organizations will be able to share their contact information via the Season >> of Docs GitHub repository, or submit proposals directly to the >> organizations, and will not need to submit a formal application through >> Season of Docs. >> >> Participating organizations will help broaden our understanding of effective >> documentation practices and metrics in open source by submitting a final >> case study upon completion of the program. The project case study will >> outline the problem the documentation project was intended to solve, what >> metrics were used to judge the effectiveness of the documentation, and what >> the organization learned for the future. All the project case studies will >> be published on the Season of Docs site at the end of the program. >> >> Organization Applications >> >> Organization applications are now open! The deadline to apply is March 26, >> 2021 at 18:00 UTC. >> >> To apply, first read the guidelines for creating an organization application >> on the Season of Docs website. >> >> Take a look at the examples of project ideas, then create a project proposal >> based on your open source project’s actual documentation needs. Your goal is >> to attract technical writers to your organization, making them feel >> comfortable about approaching the organization and excited about what they >> can achieve. >> >> Organizations can submit their applications here: http://goo.gle/3qVxArQ. >> Organization applications close on March 26 at 18:00 UTC. >> >> Technical writers interested in participating in the 2021 Season of Docs >> should read our guide for technical writers on the Season of Docs website. >> >> Please do tweet and blog about Season of Docs if you’d like to share the >> news. We want as many people to know about it as possible. We’ve provided >> logos that you can download and some example content on the press page. >> >> If you have any questions about the program, please email us at >> season-of-d...@google.com. >> >> We’re looking forward to another productive year of the Season of Docs >> program! >> >> Best regards, >> >> Kassandra Dhillon, Erin McKean, and the Season of Docs team >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Season of Docs - Announce" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to season-of-docs-annou
