Re: Why Linux is blind to this ARP reply ?
vandresv_at_gmail.com
Date: 03/25/05
- Next message: Peter T. Breuer: "Re: BASH variable problem"
- Previous message: Mark Hobley: "Re: copy file from win to nix with putty console"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 24 Mar 2005 15:09:41 -0800
At last I was able to get some time to look at the problem.
I followed every one of your links, I've studied the packets to the
last detail. I'm unable to see a difference between the ARP reply of
the router when it is replying to Windows or Linux.
I have two routers (2210 ibm), the second one (not 10.10.0.46) stopped
working completely and it did not reply to no host in my network (no
matter what OS). I hooked up my laptop with a cross cable to the
ethernet port of the router and it did work (both linux and Windows
were able to see the router). Going back to the network, the router
behaved the same way. I brought it home, and everything works there, it
replies to echo requests from any PC at home.
So both routers behave really odd, I will take it back to work again
and see if still behaves like here at home.
Any way, now I think that there is nothing wrong with Linux but these
routers are not Ethernet reliable...It could have happened with any OS
for that matter.
I am forced to have these routers for a while, so I will post any thing
I found that could fully explain this issue.
I am immensely grateful for all your time and help.
My best regards,
Andres
prg wrote:
> andres wrote:
> > No more ideas ?
> >
> > I need some pointers on how to attack this problem EVEN if it is
not
> a
> > configuration problem as I suspect.
> > I've been setting up networks for quite a while, and beleive me I
> know
> > it is not a common configuration problem if there is any at all.
> >
> > If there is some OS, kernel, module, guru outthere, please throw
some
> > pointers where I can track down something like this.
>
> Sorry to be so late getting back to you. Extra load at work and
> fighting a cold has left me pretty tired at the end of the day :(
>
> Here's what I see -- let me know if I'm wrong anywhere:
>
> -- Your 10.10.0.0 net is segmented by several routers. Are they
> running proxy arp and/or filled with static routes? Are there
multiple
> paths to different lan locations?
>
> Have you tried traceroute on Linux to see how packets are traveling
> through the lan to the IBM routers? Do Win boxes (tracert) use the
> same routes from the same location? Are the routers emitting
redirects
> for better pathways?
>
> I'm wondering if Linux does not "like" something about the arp reply.
> Eg., since IBMs are on the same (logical) subnet, Linux places the
arp
> request (bcast) directly on the wire, the IBMs reply, Linux spots
what
> it considers an inconsistency and rejects the reply. Have you
checked
> that the returned IBM MAC address is, in fact, the MAC of the IBM
> interface and not an intervening router.
>
> You may need to examine both the ethernet frames and the arp packets
in
> every detail to assure that "correct" data is being returned. That
> includes the destination IP/MAC of Linux and source IP/MAC of IBM.
How
> does it compare to what Win machines see?
>
> -- The packets _are_ getting on the wire as seen by ethereal. You
> might run ethereal on Linux so as to have the same tool available on
> both Linux and Win.
>
> If the Win boxes seem to be operating "correctly" you can use them --
> both their configuration and packets -- to find what they seem to be
> doing that Linux is not.
>
> -- Linux seems not to pick the packets off the wire -- with ethereal
> running in promisc mode?
> -- Same/similar behavior on Solaris -- not picking up arp replies.
>
> I can't imagine that Linux/Solaris would not pick up an ethernet
frame
> with the "correct" MAC destination address. How else could they
> communicate with the other lan hosts? Arp and ping are two of the
> simplest protocols around and arp is absolutely essential.
>
> Linux is pretty robust but does have it's quirks. Your host setups
> seem pretty simple, however, ie., a single nic, a single IP. Default
> IP settings should work OK. You can check the main ones here:
> $ cat /proc/sys/net/ipv4/conf/eth0/*
> 1
> 1
> 0
> 0
> 0
> 0
> 0
> 0
> 0
> 1
> 1
> 1
> 1
> 0
> $ ls /proc/sys/net/ipv4/conf/eth0/
> accept_redirects forwarding proxy_arp shared_media
> accept_source_route log_martians rp_filter tag
> arp_filter mc_forwarding secure_redirects
> bootp_relay medium_id send_redirects
>
> Googling did turn up a few similar examples, but they involved
> multi-homed hosts. One sounded _very_ much like yours, but no one
> replied (and it is several years old). So not much to go by. Here's
> the best:
> http://seclists.org/lists/linux-kernel/2005/Jan/1432.html < start
> http://seclists.org/lists/linux-kernel/2005/Jan/7132.html < solution
>
> It uses # ip route add ... to place a route in a policy routing
table.
> I really hoped you could avoid doing that if possible. Also not
sure
> how to implement the same thing on Solaris.
>
> I'm sure VmWare is not the source of your problems but not sure
how/if
> it might complicate a solution on that machine. I'm not familiar
with
> the ins-n-outs of VmWare to be of any help there.
>
> Is it possible for you or someone else to ping a Linux box _from_ one
> of the IBMs. This request may very well _place_ an arp entry for the
> IBM on the Linux box. If so, you could use it to place a static arp
> entry into Linux. You might try to use a Win host for the info
needed
> to make a static arp entry. If this works, it should apply on
Solaris
> too -- I hope ;-)
>
> Note about your current config:
> [root@helpdesk etc]# netstat -rn
> Kernel IP routing table
> Destination Gateway Genmask Flags Iface
> 10.10.0.39 10.10.1.54 255.255.255.255 UGH eth0
> Using the host IP for the GW is probably not going to work reliably.
> It should cause unicast packets to simply use loopback. Something
> like:
> # route add -host 10.10.0.39
> will use default GW to send packets and 10.10.0.0 is already in route
> table. It is usually/sometimes more reliable to install all net
routes
> before any host or GW routes.
>
> The IPs/netmasks from routing table you posted:
> net:
> 10.10.0.0 /21
> netmask:
> 255.255.248.0 (/21)
> [-byte-] [-byte-] [-byte--] [-byte-]
> [-net--] [-net--] [sub] [-- -host--]
> 11111111 11111111 11111 000 00000000 < 0.0.0.0 /21
> 00001010 00001010 00000 000 00000000 < 10.10.0.0 /21 net
> 00001010 00001010 00000 001 00110110 < 10.10.1.54 /21 eth0
> 00001010 00001010 00000 111 11111111 < 10.10.7.255 /21 bcast
> 00001010 00001010 00000 001 11001000 < 10.10.1.200 /21? default GW
> 00001010 00001010 00000 001 00000001 < 10.10.1.1 /21? GW
> 00001010 00001010 00000 000 00100111 < 10.10.0.39 /21? GW
> 00001010 00001010 00000 000 00101110 < 10.10.0.46 /21? GW
>
> 00001010 00001010 11010 000 00000000 < 10.10.208.0 /21
> 00001010 00001010 11011 000 00000000 < 10.10.216.0 /21
>
> net:
> 10.10.96.0 /19
> netmask:
> 255.255.224.0 (/19)
> [-net--] [-net--] [sub] [-----host---]
> 11111111 11111111 111 00000 00000000 < 0.0.0.0 /19
> 00001010 00001010 011 00000 00000000 < 10.10.96.0 /19
> 00001010 00001010 000 00001 00000001 < 10.10.1.1 /21? GW
>
> I'm sending these links along in case they are informative/useful:
> http://linux-ip.net/html/
> Basic and advanced Linux networking doc
>
> http://snafu.freedom.org/linux2.2/docs/ip-cref/ip-cref.html
> _The_ doc for Linux's ip utility. See especially:
> # ip link show
> # ip route show
> # ip route get <<
> # ip route add
> # ip neighbour ... <<
> # arping << command line utility
>
> http://www.policyrouting.org/PolicyRoutingBook/ONLINE/TOC.html
> Linux policy routing "in depth"
>
> http://www.networksorcery.com/enp/protocol/arp.htm
> arp packet format, options, and codes
>
> http://www.watchguard.com/infocenter/editorial/135324.asp
>
http://www.google.com/search?num=50&hl=en&lr=lang_en&ie=ISO-8859-1&q=windows+arp+request+cache
>
http://groups-beta.google.com/group/comp.protocols.tcp-ip/search?group=comp.protocols.tcp-ip&q=linux+arp+reply+cache&qt_g=1
>
> If I keep going I'll make your hair fall out, so I'll stop now and
hope
> there is something useful here ;-)
>
> The main thing at this point is that you will have to see if you can
> ping from Linux to next hop, to next hop, etc., to IBM. Watch
packets,
> compare to traceroute path, ping traceroute path point by point.
> Compare to Windows output.
>
> Try a static arp table entry once you have the "correct" MAC address
> for IBM. Is "correct" the MAC on the IBM interface or the MAC of a
> "router" that is shuttling packets? (EG., _all_ arp entries on this
> solo box at home match IPs to the default GW MAC).
>
> Tedious, probably uneeded, but do double check that Win is using the
> same MAC as Linux (on the dual OS or boot machine) in its arp
requests.
> Check options in packets while you're at it. I would hate to think
> that MS and IBM are talking via some "optimized" feature/flag from
> LanMan days before IBM recognized MS as its nemesis.
>
> There has to be _something_ that is different in the way Win is
talking
> to the IBMs that Linux and Solaris are not/cannot duplicate. That or
> something in the Win IP stack that works OK in a "routed" IP subnet
> address space. Sure hope there is a better solution than policy
> routing.
>
> There may be a couple of other things I have forgotten to suggest,
but
> surely this is enough (too much?) for now. If anything comes to me
> tomorrow, I'll try to get it posted earlier.
>
> good luck and let us know how it's going,
> prg
> email above disabled
- Next message: Peter T. Breuer: "Re: BASH variable problem"
- Previous message: Mark Hobley: "Re: copy file from win to nix with putty console"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
