TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

From Oscilloscope to Wireshark: A UDP Story

298 点作者 mkeeter将近 3 年前

14 条评论

Animats将近 3 年前
If you have to debug at that level, and you&#x27;re not designing hardware, things are really bad.<p>Some years back, Wes Irish at Xerox PARC tracked down one of the great mysteries of early coax Ethernet - why was throughput so much lower than theory predicted? For this, he got both ends of a building-length coax with many machines on it connected to one office, so he could plug both ends into a storage scope. If the waveforms disagreed, somebody was transmitting when they shouldn&#x27;t. Storage scopes with large storage were rare then. It was an expensive LeCroy unit.<p>After the end of each Ethernet packet on coax, there is a brief &quot;quiet time&quot;, and then the next packet can be sent, beginning with a sync pattern. The hardware detects if what it is sending does not match what it is receiving, which indicates a collision. Both senders stop, wait a random time so they don&#x27;t collide again, and retry. This is how &quot;carrier sense multiple access - collision detection&quot;, or CSMA-CD, works at the hardware level.<p>This setup revealed that something on the cable was transmitting a single spike after the end of each packet, during the &quot;quiet time&quot;. That reset the &quot;quiet time&quot; timer in the network interface, which inhibited the transition to &quot;look for sync&quot; mode. So the next packet would be ignored. The quiet time timer was at a very low level - software did not see this event.<p>What came out of looking at the waveforms was the surprising result that the spike during the quiet time was not coming from either the data source or the destination, but from something elsewhere on the cable. The spike was not synchronized to the packet just sent. With the waveforms for both ends of the cable visible, speed of light lag revealed both that this was happening and where it was coming from, as distance along the cable.<p>It turned out that several brands of network interface used a part which contained the quiet time timer, the sync recognizer, and the transmitter power controller. When the timer ran out, the device did a state machine transition, and during that transition, for a nanosecond or so, the transmitter turned on. It wasn&#x27;t supposed to do that. This generated a spike on the cable, resetting every quiet time timer and causing the next packet to be silently ignored by all stations.<p>The network interface didn&#x27;t need to be active to do this. Being powered on was sufficient. One device with that part could halve the data rate on a coax Ethernet. Thousands of network interfaces had to be scrapped to fix this.
评论 #32435385 未加载
评论 #32432155 未加载
评论 #32434870 未加载
评论 #32432257 未加载
anonymousiam将近 3 年前
I know a little bit about Ethernet, having used it since the early 10Base-2 days as well as having done a bit of &quot;hacking&quot; in an effort to decode 1000Base-T.<p>This article is focused on the QSGMII PHY chip, without which it would be practically impossible to use an oscilloscope for any meaningful troubleshooting.<p>1000Base-T is the most commonly used Ethernet variant in use today. It uses four balanced differential pairs for signalling. Each pair transmits and receives simultaneously. This works because 1000Base-T is a point-to-point connection and the PHY contains a hybrid that subtracts the voltage being transmitted from what is received. This makes the problem of &quot;tapping&quot; the interface harder because the third party observer sees a jumble of data and cannot easily determine what data is coming from either of the two connected devices. Each pair can send&#x2F;receive five possible symbols, represented by voltages of +3.5, +2, 0, -2, -3.5 volts. In addition, the PHY &quot;scrambles&quot; the data being sent with a LFSR (<a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Linear-feedback_shift_register" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Linear-feedback_shift_register</a>) seeded with either a &quot;master&quot; or &quot;slave&quot; value. (The master&#x2F;slave identity is negotiated between the two peers when they detect each other.) It gets even more complex with hamming codes and an abstraction layer to separate the control&#x2F;data planes. There&#x27;s also a complicated DSP for line equalization.<p>BTW, I do own one of these: <a href="https:&#x2F;&#x2F;www.amazon.com&#x2F;midBit-Technologies-LLC-SharkTapUSB-100&#x2F;dp&#x2F;B01N370ZQV" rel="nofollow">https:&#x2F;&#x2F;www.amazon.com&#x2F;midBit-Technologies-LLC-SharkTapUSB-1...</a> which can make the job very easy, but it was not an available option for my &quot;hacking&quot; application.
thatcherc将近 3 年前
The scope&#x27;s sample rate really jumped out to me:<p>&gt; I configured the oscilloscope to collect 100M samples at 1 TSPS (tera-sample per second, 10^12) ...<p>Wow! Sampling at 1000 GHz? I wouldn&#x27;t have thought that was possible! Does anyone know how the scope can even do that?
评论 #32429011 未加载
评论 #32429191 未加载
评论 #32429159 未加载
评论 #32433632 未加载
nazgulsenpai将近 3 年前
There are so many levels of mind-boggling engineering between the analog electrical signal going into the PSU to the packets travelling across the wire&#x2F;air that I take for granted. This post really helps me visualize how complex even the simplest of network processing truly is.<p>Thank you!
matthberg将近 3 年前
For oscilloscope&#x2F;logic analyzer work I&#x27;ve encountered Sigrok as the goto tool to use (yet I have not used it myself yet, lacking the hardware at the moment). They have suites of different parsers for nearly every network protocol, which can also be applied on top of each other.<p><a href="https:&#x2F;&#x2F;sigrok.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;sigrok.org&#x2F;</a>
评论 #32439772 未加载
ChrisMarshallNY将近 3 年前
Excellent post. As an EE that turned soft, articles like this make me smile.
评论 #32434071 未加载
jeffrallen将近 3 年前
Being able to recruit people like Matt is why Oxide will win.<p>Go team Oxide, we&#x27;re rooting for you!
评论 #32451244 未加载
jzer0cool将近 3 年前
Speaking of oscilloscope is there any analyzer recommended which is versatile and for budget use? Mainly for reading voltage readings and for capturing data packets. Under $100 USD.
评论 #32452270 未加载
评论 #32451222 未加载
phibz将近 3 年前
It&#x27;s nice to see rust in an article not about rust.
mpalme将近 3 年前
Posts like these are the reason I come here. Kudos!
评论 #32432842 未加载
justinsaccount将近 3 年前
Can those scopes transmit the data in real time somehow?<p>It would be neat cause then you could wrap the decoding bits in a library that implement the libpcap interface. Then any existing tool like tcpdump&#x2F;tshark&#x2F;zeek would just work and it would effectively be a software defined network tap.
评论 #32433493 未加载
TheDesolate0将近 3 年前
&quot;Man, python sure looks a lot like rust, these days!&quot; -- My Brain, reading this article...
sitzkrieg将近 3 年前
nice writeup! and i thought RMII was hard to deal with
ru552将近 3 年前
Thank you. This was a great read.