From: "Ron Watkins" <xen-devel@malor.com>
To: xen-devel@lists.sourceforge.net
Subject: ARP problems in -testing?
Date: Sun, 16 Jan 2005 11:42:42 -0500 [thread overview]
Message-ID: <000e01c4fbea$6652adb0$32dcdc0a@vanish> (raw)
I'm seeing something rather unusual that I thought might be an ARP problem,
but further testing appears to have ruled that out.
Scenario: slave domains with random ARP addresses. On a fresh start of a
domain, it is unreachable from outside. Pinging from Domain 0 to the slave
domain work fine, but changes nothing.
Here's the interesting part: pinging from the slave domain to any external
host, including Domain 0, also works... and immediately 'unsticks' the net
connection, so that everything works as I expect it to.
This seems to happen with or without my firewalling rules. (I disable the
antispoof section of the 'network' script, so that the firewall rules there
don't interfere with mine.)
My initial theory was that it's an ARP problem. I thought the outbound
packet was being bridged properly to the outside world, the router saw the
arp address, and started working. But this does not appear to be correct.
If I add a secondary IP to the eth0 inside the virtual domain, I do indeed
see arp requests and arp replies.
When it is in 'stuck' mode, running a tcpdump from the SLAVE domain shows
the echo requests arriving: [ips changed to protect the morally
questionable]:
16:36:54.694003 IP 24.0.0.10 > 69.0.0.76: icmp 40: echo request seq 2344
But there are no replies issued. After I ping the outside world, which
instantly 'wakes up' the connection:
16:38:57.212284 IP 24.0.0.10 > 69.0.0.76: icmp 40: echo request seq 11816
16:38:57.212314 IP 69.0.0.76 > 24.0.0.10: icmp 40: echo reply seq 11816
This is from a brand-new download today, btw.
I am really mystified. Any suggestions?
-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
next reply other threads:[~2005-01-16 16:42 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-01-16 16:42 Ron Watkins [this message]
2005-01-16 18:30 ` ARP problems in -testing? Felipe Alfaro Solana
2005-01-16 18:49 ` Ron Watkins
2005-01-16 19:18 ` Jan Kundrát
2005-01-16 20:11 ` Keir Fraser
2005-01-17 0:27 ` Derrik Pates
2005-01-17 0:58 ` Felipe Alfaro Solana
2005-01-17 1:33 ` Adam Sulmicki
2005-01-17 13:41 ` Keir Fraser
2005-01-17 14:27 ` Felipe Alfaro Solana
2005-01-17 10:39 ` Ron Watkins
2005-01-17 11:14 ` Keir Fraser
2005-01-16 22:44 ` Felipe Alfaro Solana
2005-01-16 22:39 ` Felipe Alfaro Solana
-- strict thread matches above, loose matches on Subject: below --
2005-01-16 17:46 Ian Pratt
2005-01-16 18:33 ` Ron Watkins
2005-01-16 18:51 ` Ron Watkins
2005-01-17 1:23 Ian Pratt
2005-01-17 2:03 ` Adam Sulmicki
2005-01-17 1:41 Ian Pratt
2005-01-17 14:08 Tim Durack
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='000e01c4fbea$6652adb0$32dcdc0a@vanish' \
--to=xen-devel@malor.com \
--cc=xen-devel@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.