Sun Jun 24 15:58:43 UTC 2012
On Sun, 24 Jun 2012 16:33:43 +0200, Vernon Schryver <firstname.lastname@example.org> wrote: >> From: "Ronald Klop" <email@example.com> > >> I am trying to run dccproc/dccifd on FreeBSD-9/arm. I get no response on >> the UDP request. I suspected firewall issues so I tried it on my desktop >> FreeBSD-9/amd64 and there everything works well. >> The output of ngrep looks different on the same e-mail. > > The DCC client-server protocol is purely binary and involves no > text. Every request and response packet, including retransmissions > of a request, should have a unique combination of transaction ID > and other bits. > > I think there was once an Ethereal DCC decoder. A recent Wireshark > DCC decoder seems to understand at least some DCC requests from > clients but responses from servers not so much. I've never used > either one. > >> I don't know >> what >> to think about that, but maybe the udp packet is 'corrupted' on arm. >> Is this a known issue? > > It's news to me. > >> What can I provide to debug this? > > I would first check for an IPFW firewall on the FreeBSD-9/arm system. > Then I would try: > > `cdcc info` > > cdcc "host x.dcc-servers.net; rtt" > > see if cdcc and then dccproc can talk to a DCC server running on > the local machine. If that works, then my guess would involve > compiler or kernel network bugs. > > > Vernon Schryver firstname.lastname@example.org > Cdcc info works and the network traffic looks ok. So I do not see a firewall issue. Wireshark (1.8) gives some interesting outcome. Here are the dump files. https://dl.dropbox.com/u/74961258/dump-amd64.pcap https://dl.dropbox.com/u/74961258/dump-arm.pcap The first md5 sum is shifted 2 bytes in dump-arm. amd: 28:49:3c:d1:60:ac:70:13:16:df:e6:a7:d7:0c:4c:e4 arm: 08:20:28:49:3c:d1:60:ac:70:13:16:df:e6:a7:d7:0c The length field of the checksum says 36 on arm and 18 on amd64. And the arm value looks padded with 0's at the end. Ronald.
More information about the DCC