On 10/23/06, Peter Jakobi <[EMAIL PROTECTED]> wrote:
0. both sides CAN boot? Network cards blink all ports inbetween on traffic?
Of course. ICMP echo is ok both ways.
2. braindead switch: try pinging it from both sides and switch to another switch/port... - the route might be asymmetric, too... traceroute from both, tcpdump from both, arp -v -d OTHER_HOSTNAME on both...
Everything works.
3. ahem. you DID check that the interface cfg is ok for both sides?
Sure.
assuming that you've an onboard ethernet: New port might mean new mac might mean suse not knowing which IP to configure, as it detects a difference between the previous and the new network card [I hate the change that added that much "intelligence"!]
Networking configuration was re-created. It works, apart from the fact that ssh does not get incoming packets.
switching pci boards around? 4. electrostatics killed the cat^H^H^H part of a chip [or something like that]?
Networking works perfectly on both sides. They work just about as well as they can.
>SuSEFirewall is dropping the packets as new board has a new >mac, but no. Disabling firewall made zero difference. Next >guess was to disable AppArmor, but no luck there either. >If I start sshd with -d on console I can see that it doesn't >get the connection. Tcpdump does see the incoming packets >though, so kernel must be dropping them. still way too high, stick too the basics first...
All the basics are ok.
strace -f PID of your sshd might work, too, if you're using it as a standalone daemon.
But which process to strace? Daemon is ok, it's just not getting the packets. ssh -v from the client only yields 'connecting..'. For some reason host is filtering traffic without active firewall (iptables -L). -- // Janne --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
