[sane-devel] Is support for cat5 interfaces of Brother products possible?
jmozdzen at nde.ag
Mon May 23 15:41:38 UTC 2016
Zitat von Gene Heskett <gheskett at shentel.net>
> Greetings all;
> This scanner in an MFC-9620DW works well with the brother drivers if one
> is not in a hurry.
> I investigated the delays and found the networking portion of the Brother
> Drivers are sending the first 6 packets, at 1 second intervals, with
> bad TCP checksum according to tcpdump. The scanner of course rightfully
> ignores them.
it might be you're barking up the wrong tree: The bad checksums
reported by tcpdump may likely be caused by offloading CRC calculation
to the network card. Of course, if you were capturing at the scanner's
end, you'd be right in your assumption.
What type of packets are those six? TCP session establishment? ARP?
Other? Can you tell what the printer sends (probably to some totally
different host, i.e. DNS server - you'd need to capture at the
scanner's port) when receiving these packets?
> Then their driver seems to get it all in the same sock for
> the rest of the scan. I have not traced a multisheet scan as yet, but
> this 7 seconds delay is present regardless of whether the sheet is on
> the glass, or in the in hopper of the ASF.
I've had a close look at brsane4 network traffic when debugging a
problem with a networked Brother scanner and I don't remember seeing
these unanswered packets at the start of the scan. That was a remote
scanner though, crossing routers and a VPN tunnel to connect. And
connected via WLAN at the scanner's site.
We have older on-site Brother MFCs used as printers and scanners,
connected via local Ethernet (most likely what you call "cat5
interface"). These have shown not to be instantaneous during
operation, but I'd name the slow processors in those boxes as the
> This has been reported to Brother twice now, but no one has responded
> with a fix.
Getting to the right person can be troublesome, indeed. Been there,
but later met the right person and got the brsane4 driver fixed, based
on our findings.
Maybe it's some different network problem, after all, or related to a
device wake-up upon seeing the first packets?
More information about the sane-devel