Comments inline. I added the LEAF list back in.

At 03:49 PM 12/12/01 -0500, Dr. Richard W. Tibbs wrote:
...
>> 1. Is the SuSE host running any firewalling of its own? On it, does
>> "ipchains -L -n" report anything interesting?
>
>Keep in mind that without modification the Suse box has successfully 
>pinged another doorstop box with TomsRootBoot running just to check it 
>out.  Worked through same cables, same hub. That additional doorstop
>is now turned off and disconnected from hub; new dachstein box plugged 
>in and running.

<sigh> I sure wish you had mentioned this earlier. I couldn't keep this "in
mind" before now because you hadn't mentioned it in your earlier trouble
reports (or did you and I missed it?). This information changes my focus a
lot in thinking about the problem ... it makes a lot of my prior questions
irrelevant.</sigh>

OK. Now, a very basic question ... are you sure you have eth0 and eth1 on
the DachStein router associated with the right NICs? That is, might you have
eth0 (the external, as yet unconfigured interface) connected to the hub
instead of eth1 (the internal interface assigned to 192.168.1.2)? 

Since you say below (not sure if this is with respect to the NICs, the hub,
or both, but for this purpose it doesn't matter) --

>They have traffic as well, but I have observed no "flickering" -- 
>indication of traffic activity

-- this sort of misconiguration is the first thing that comes to mind.

The second possibility is that some more general rule, or one of the default
DENY policies, on the DachStein router (one where proto=ALL) is blocking the
pings. This is improbable, if you stayed close to the default ruleset ...
but your reporting of the "icmp-relevant lines" doesn't cover all the bases. 

As you summarize the input chain on the DachStein router, it DENYs
everything (the default policy is DENY, and the only lines you list or
summarize below are DENYs and REJECTs). Actually, so do the forward and
output chains, as you summarize them. But then your reply to question 2
lists a couple of ACCEPT lines (uninterpretable in isolation; we call them
"rulesets" because they only have meaning when viewed as a set).

So ... I don't know if your edited report in question 1 left out some ACCEPT
lines or if the router really is as misconfigured as your summary suggests.
But your logs (probably /var/log/messages) should indicate if the router is
DENYing a lot of traffic, it should be logging those DENYs.

If it is a DachStein-specific misconfiguration, someone who is currently
running DachStein can suggest the likely locations for the error. A response
that is not specific to DachStein still requires an accorate listing of the
full rulesets.

>Suse box ipchains output  has
>Chain input (policy ACCEPT)
>target    prot    opt        source       dest           ports
>DENY   udp  ----l-  0.0.0.0/0  0.0.0.0/0  *-> 0:1023
>(a couple of other udp and tcp flavors)
>DENY   icmp  ----l-  0.0.0.0/0  0.0.0.0/0  8-> *
>Chain forward (policy ACCEPT)
>target     prot    opt       source       dest           ports
>MASQ  all      ------    0.0.0.0/0   0.0.0.0/0    n/a
>Chain output (policy ACCEPT) :
><no entries>
>
>The ipchains -L -n output on the Dachstein box is voluminous but the 
>icmp-relevant lines are
>Chain input (policy DENY)
>target    prot    opt        source       dest           ports
>DENY   icmp  ----l-  0.0.0.0/0  0.0.0.0/0  5-> *
>DENY   icmp  ----l-  0.0.0.0/0  0.0.0.0/0  13-> *
>DENY   icmp  ----l-  0.0.0.0/0  0.0.0.0/0  14-> *
>< bunch of DENY all >
>DENY  all      ----l-  192.168.1.0/24  0.0.0.0/0  n/a
>DENY  all      ----l-  192.168.1.254.254  0.0.0.0/0  n/a
>REJECT  all      ----l-    0.0.0.0/0 192.168.1.0/24    n/a
>Chain forward (policy DENY)
>target    prot    opt        source       dest           ports
>DENY   icmp  ----l-  0.0.0.0/0  0.0.0.0/0  5-> *
><scads of other DENYs>
>Chain output (policy DENY)
>target    prot    opt        source       dest           ports
>fairq     all   ------      0.0.0.0/0     0.0.0.0/0  n/a
>DENY all   ----l-      0.0.0.0        0.0.0.0/0  n/a
><lost of DENYs but no icmp>
>Chain fairq 
><bunch of RETURNs>
>
>So, is possible I need to only deny port 8-> *
>to be able to ping ?
>But I am not an ipchains maven (yet).
>
>> 
>> 2. Do the logs on the DachStein router report any DENY'd or REJECT'd icmp
>> packets? Does "ipchains -L -n -v" report any rules that would seem to be
>> blocking the icmp traffic?
>
>With -v added, I see pkts and bytes are all 0's  except the rules
>Chain input
><yadda>
>pkts    bytes      target     proto   options    tosa   tosx       
>ifname mark      outsize source
>  85   9184     ACCEPT  all       -------     0xFF 0x00       *        
>0x1                  0.0.0.0/0
>Chain output
><yadda>
>pkts    bytes      target     proto   options    tosa   tosx       
>ifname mark      outsize source
>158  15316     ACCEPT  all       -------     0xFF 0x00       *        
>0x1                  0.0.0.0/0
>
>> 
>> 3. After you attempt and fail to ping the SuSE device, does the DachStein
>> router's arp table show an entry for the SuSE device? ("more
>> /proc/net/arp")? Does the SuSE host have an arp entry for the DachStein
router?
>
>this shows no entries.
>I had enabled arp on eth1, by the way via "ip link eth1 arp on".
>
>> 
>> 4. This is a real long shot, but ... what is in
>> /proc/sys/net/ipv4/icmp_echo_ignore_all on the SuSE host? It's probably 0
>> [=FALSE], as it should be. If it is a 1 [=TRUE], change it to 0 (" echo 0 >
>> /proc/sys/net/ipv4/icmp_echo_ignore_all", I think) and see if that changes
>> your results.
>
>icmp_echo_ignore_all
>contains a
>0
>on both machines
>
>> 
>> 5. Could the hub itself be bad? Do you have a crossover cable (or another
>> hub) you can use to connect the two hosts directly?
>
>The hub worked fine before (between Suse box and earlier doorstop)
>
>
>> 
>> 6. You mentioned "appropriate green led's" lighting up. Do the NICs and hub
>> ports have only "connect" LEDs, or do they have "traffic" LEDs as well?  If
>> they have both, do they all behave as expected?
>
>They have traffic as well, but I have observed no "flickering" -- 
>indication of traffic activity
>
>> 
>> 7. Finally ... have you tried any connections other than pings? I don't know
>> what services the SuSE host is running, so I cannot be more specific here.
>> 
>> 8. And plu-finally ... have you tried and failed in the other direction too?
>> Can the SuSE host ping, or or connect towhatever else is running in the way
>> of services on, the DachStein router?
>
>Yes I tried ping in both directions.....
>
[html deleted]


--
------------------------------------"Never tell me the odds!"---
Ray Olszewski                                        -- Han Solo
Palo Alto, CA                                    [EMAIL PROTECTED]        
----------------------------------------------------------------


_______________________________________________
Leaf-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user

Reply via email to