 |  |  |  |  |  |  |  |  |  |
Chappell Seminars
TM
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
| Recent Blog Entries (RSS Feed) |
| [R] Recorded course available - included in All-Access Pass (additional recordings in production) |
| COURSE LIST (View Schedule) |
50% off Summit 09 Registration More info
Summit 09 50% off for
All Access Pass Members
All Access Pass Members
Posted: 2009-10-27 10:19:54 UTC-07:00
Summit 09 Bonus: Licensed NetScanTools Pro - a $249 Value
All Summit 09 attendees will receive a full licensed copy of
NetScanTools Pro – a $249 value.
It's not easy going "green"... I mean - all we wanted to do was print the customized
course manuals double-sided. What's the big problem?
WIRESHARK and I NEARLY BARFED!
<claw_extensions=on>
First let me say I was printing to an HP OfficeJet Pro L7780 All-in-One printer - it
supports auto-duplexing. The feature is implemented in the most funky way
however! Watching the traffic live while the printer did it's 'dance of duplex' - I was
shocked to see the lame process of auto-duplex printing.
I had to wonder if the HP printer group might be interested in
some classes on networking.*
Ok... here's how this printer does duplex printing. It's automatic, so you don't have
to do the old 'refeed the paper and hope it's in the right order' process. You just
select auto-duplex and away it goes. The printer prints the first page and - while
still holding the paper by the bottom edges, the console reads "Ink drying - please
wait." After a while the paper is then sucked back into the printer (a moment that
always makes my heart jump - I've heard the shredding sound of mangled paper
too many times). The second side of the paper prints and we all sigh relief -
another 2-sided page done!
The trace file showed that the printer creates the pause process by sending a
Zero Window packet to the client - in essence "talk to the hand" (isn't that HP's
little helper logo?). Each 'drying process' essentially was caused by halted flow of
print data from my client to the printer. My client sent Zero Window Probe packets
to ask 'What is wrong with you, buddy?" and the printer kept the traffic at bay by
sending Zero Window Probe ACKs for about 30 seconds.
The printer's TCP window size did decrease down to an unacceptable zero so it
wasn't lying about not having any receive buffers. It seems the printer doesn't
clear out the buffer space consistently during the print process - it's buffer
becomes depleted right at the point when the 'ink needs to dry" - perhaps it knows
we'll all need to take a breath then so allowing the buffer to fill doesn't seem like a
big deal - it's going to have to sit around idle anyway (anyone think about adding a
nice 'ink fan' attachment to make my printing go faster?).
I decided to add a tcp.window_size column and filter on traffic coming from the
printer. Using File > Export > File and choosing the displayed packets, I created a
csv file with a column just depicting the TCP receive window sizes advertised by
the printer. In Excel I selected only the tcp.win_size column and inserted a line
graph.
BEAUTI-FRIGGIN-FUL! Look at the intentional pattern of the window size values
advertised with definite zero window conditions during the ink drying time.
There's just got to be a better way!
Want to make pretty charts and graphs of the tcp.window_size data? Download
the .csv file I worked with.
What? Is my printer totally dumb? I didn't think so, but this is certainly dumb
behavior. The file is only 13,296 KB! The printer has 64 MB memory standard.
Why didn't the printer allow me to send the entire document to the printer, then
buffer the data while the ink dried? Why did I have to sit around and wait for the ink
to dry before being able to send the next page of data? The Wireshark summary
of the data sent to the printer showed the transmission rate averaged around
0.431 Mbit/second - snooze...
I also look at the spooled file in my Windows\System32\spool\PRINTERS
directory - holy schmoley! The spooled file (.spl) was 670,016 KB! Whazzup with
that? The idea of researching the MS spooling process and .spl file format made
my stomach turn again - but it did look like this Powerpoint Notes document was
processed as a graphics file.
Then came the really interesting part - I printed twenty-five copies of the custom
student manual. You'd think the printer would have buffered the first copy in
memory and just pulled from that when it needed to make each successive copy -
right? Nope. My client sent the entire file to the printer a second time, a third time,
a fourth time... etc. Whoa... that's one dumb process! No turning off my system
until the entire job was sent 25 times from the spool\PRINTERS directory. Barf.
Basic network analysis should be a mandatory requirement for any vendor
making network-capable devices/applications - or else they might make a
network-incapable devices/applications - oh wait - they do!
<claw_extensions=off>
Enjoy life one bit at a time!
Laura
*Although this is the lamest way to get the job done, I swear by my HP printers -
they take a beating and keep on spitting out surreal amounts of pages every
month - I am a tactile, visual person - there's nothing like that printed version of
the spec to snuggle up with at night! So much for going green. (The only green
that will fly around here will be some big $ for printers that can buffer the entire
doc once - without the 'talk to the hand process' - and then print extra copies from
that!)
Summit 09 Bonus: Licensed NetScanTools Pro - a $249 Value
All Summit 09 attendees will receive a full licensed copy of
NetScanTools Pro – a $249 value.
It's not easy going "green"... I mean - all we wanted to do was print the customized
course manuals double-sided. What's the big problem?
WIRESHARK and I NEARLY BARFED!
<claw_extensions=on>
First let me say I was printing to an HP OfficeJet Pro L7780 All-in-One printer - it
supports auto-duplexing. The feature is implemented in the most funky way
however! Watching the traffic live while the printer did it's 'dance of duplex' - I was
shocked to see the lame process of auto-duplex printing.
I had to wonder if the HP printer group might be interested in
some classes on networking.*
Ok... here's how this printer does duplex printing. It's automatic, so you don't have
to do the old 'refeed the paper and hope it's in the right order' process. You just
select auto-duplex and away it goes. The printer prints the first page and - while
still holding the paper by the bottom edges, the console reads "Ink drying - please
wait." After a while the paper is then sucked back into the printer (a moment that
always makes my heart jump - I've heard the shredding sound of mangled paper
too many times). The second side of the paper prints and we all sigh relief -
another 2-sided page done!
The trace file showed that the printer creates the pause process by sending a
Zero Window packet to the client - in essence "talk to the hand" (isn't that HP's
little helper logo?). Each 'drying process' essentially was caused by halted flow of
print data from my client to the printer. My client sent Zero Window Probe packets
to ask 'What is wrong with you, buddy?" and the printer kept the traffic at bay by
sending Zero Window Probe ACKs for about 30 seconds.
The printer's TCP window size did decrease down to an unacceptable zero so it
wasn't lying about not having any receive buffers. It seems the printer doesn't
clear out the buffer space consistently during the print process - it's buffer
becomes depleted right at the point when the 'ink needs to dry" - perhaps it knows
we'll all need to take a breath then so allowing the buffer to fill doesn't seem like a
big deal - it's going to have to sit around idle anyway (anyone think about adding a
nice 'ink fan' attachment to make my printing go faster?).
I decided to add a tcp.window_size column and filter on traffic coming from the
printer. Using File > Export > File and choosing the displayed packets, I created a
csv file with a column just depicting the TCP receive window sizes advertised by
the printer. In Excel I selected only the tcp.win_size column and inserted a line
graph.
BEAUTI-FRIGGIN-FUL! Look at the intentional pattern of the window size values
advertised with definite zero window conditions during the ink drying time.
There's just got to be a better way!
Want to make pretty charts and graphs of the tcp.window_size data? Download
the .csv file I worked with.
What? Is my printer totally dumb? I didn't think so, but this is certainly dumb
behavior. The file is only 13,296 KB! The printer has 64 MB memory standard.
Why didn't the printer allow me to send the entire document to the printer, then
buffer the data while the ink dried? Why did I have to sit around and wait for the ink
to dry before being able to send the next page of data? The Wireshark summary
of the data sent to the printer showed the transmission rate averaged around
0.431 Mbit/second - snooze...
I also look at the spooled file in my Windows\System32\spool\PRINTERS
directory - holy schmoley! The spooled file (.spl) was 670,016 KB! Whazzup with
that? The idea of researching the MS spooling process and .spl file format made
my stomach turn again - but it did look like this Powerpoint Notes document was
processed as a graphics file.
Then came the really interesting part - I printed twenty-five copies of the custom
student manual. You'd think the printer would have buffered the first copy in
memory and just pulled from that when it needed to make each successive copy -
right? Nope. My client sent the entire file to the printer a second time, a third time,
a fourth time... etc. Whoa... that's one dumb process! No turning off my system
until the entire job was sent 25 times from the spool\PRINTERS directory. Barf.
Basic network analysis should be a mandatory requirement for any vendor
making network-capable devices/applications - or else they might make a
network-incapable devices/applications - oh wait - they do!
<claw_extensions=off>
Enjoy life one bit at a time!
Laura
*Although this is the lamest way to get the job done, I swear by my HP printers -
they take a beating and keep on spitting out surreal amounts of pages every
month - I am a tactile, visual person - there's nothing like that printed version of
the spec to snuggle up with at night! So much for going green. (The only green
that will fly around here will be some big $ for printers that can buffer the entire
doc once - without the 'talk to the hand process' - and then print extra copies from
that!)
Printers are
Double Dumb?
Double Dumb?
ALL ACCESS PASS
includes Core 1, Core 2, Whiteboard
Videos, Ask Laura Videos, Trace File
Videos, Trace Files and access to all the
recorded Chappell Seminars.
[View the All Access Info PDF...]
Single membership; individual account
info@chappellU.com
includes Core 1, Core 2, Whiteboard
Videos, Ask Laura Videos, Trace File
Videos, Trace Files and access to all the
recorded Chappell Seminars.
[View the All Access Info PDF...]
Single membership; individual account
info@chappellU.com
$999
REGISTER FOR WEEKLY NEWS
Copyright Chappell University
All Rights Reserved
Privacy Policy
All Rights Reserved
Privacy Policy
20+ years of analysis experience and 10+
years of Wireshark/Ethereal experience
rolled into a single book.
- Forward by Gerald Combs, Creator of
Wireshark
- Practical tips throughout
- Basic through advanced techniques
- Undocumented features
- Exporting for reporting tricks
- Find the needle in the haystack
- Analyze unruly applications
- Spot the cause of slow web browsing
- Identify WLAN problems
- Analyze and replay VoIP connections
- Reassemble traffic of all kinds
- Catch scanning/discovery processes
- Hundreds of sample traffic files to work on
- Chapter review/answer sections
- Real world case studies
- Tricks for command-line capture
- Remote capture solutions
- Decrypting SSL traffic
- Tips for capturing on switched nets
- Custom profile configurations included
- Security color filters included
- more...
Sign up for the newsletter to be notified of
the book release!
years of Wireshark/Ethereal experience
rolled into a single book.
- Forward by Gerald Combs, Creator of
Wireshark
- Practical tips throughout
- Basic through advanced techniques
- Undocumented features
- Exporting for reporting tricks
- Find the needle in the haystack
- Analyze unruly applications
- Spot the cause of slow web browsing
- Identify WLAN problems
- Analyze and replay VoIP connections
- Reassemble traffic of all kinds
- Catch scanning/discovery processes
- Hundreds of sample traffic files to work on
- Chapter review/answer sections
- Real world case studies
- Tricks for command-line capture
- Remote capture solutions
- Decrypting SSL traffic
- Tips for capturing on switched nets
- Custom profile configurations included
- Security color filters included
- more...
Sign up for the newsletter to be notified of
the book release!
RELEASE: MARCH 2010
Review the Table of Contents
Peek at sample pages
Peek at sample pages