Dean,
You 're right about using a unicast mac address , but after doing that
it goes even worse.
It seems that ngeth0 denies to accept (and forward to upper layers) to
any traffic sees,
for some reason. After placing static arp entries in both boxes
(freebsd+remote) i have
the same behavior (as multicast):
o physical interface works fine(traffic flows on both directions).
o app:stack-->ngeth0:ng0---->xl0:low--->wire [WORKS]
o wire --->xl0:low--->ng0:ngeth0--->stack:app [FAILED]
tcpdump here(ngeth0) shows traffic (incomming
only)
I'm really stuck here...
Chris.
Dean Strik wrote:
Chris Dionissopoulos wrote:
and for every ng_eiface node you attach you must provide a
mac address for filtering (later this will be automated).
[..]
gw0#ifconfig ngeth0
ngeth0:
flags=28943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST,PPROMISC> mtu
1500
inet6 fe80::260:8ff:fee8:589e%ngeth0 prefixlen 64 scopeid 0x6
inet 192.168.1.2 netmask 0xffffff00 broadcast 192.168.1.255
ether 01:02:03:04:05:00
Traffic initiated localy flows prefectly through ngeth0 and xl0
interfaces, but
this is not happen for traffic that comes from outside. It seems that
doesn't
arrive to ngeth0 upper level protocols.
Haven't looked at the code, but I'm just wondering here... this MAC
address is a multicast address, not a unicast one. Should that work as
expected at all?
____________________________________________________________________
http://www.freemail.gr - δωρεάν υπηρεσία ηλεκτρονικού ταχυδρομείου.
http://www.freemail.gr - free email service for the Greek-speaking.
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
