Stefano Marinelli <postnet%dragas.dyndns.org@localhost> writes: >> Can you explain how this is supposed to work? I don't understand why >> you think tun interfaces are part of this. Perhaps tap? > > No, it's tun. As far as I've read (and tested), the tap interface > works only on Linux. > Actually it starts a tun interface (with a local ip address, usually > 192.168.182.1) and an internal dhcp server on it. Then it starts to > listen (bridge?) on the lan specified interface (in my situation, it's > re0) and whenever a client asks for an ip, it assigns one of those > local ips. You haven't explained *how* it's supposed to work, just what it's supposed to do. As I understand it, tun(4) will provide IP packets and tap(4) will appear to be an Ethernet. I wouldn't expect that one can bridge a tun and an ethernet (with brconfig(8)). > The problem is: I can see, using tcpdump, the requests coming on the > physical re0 interface, but there are no replies. And tcpdump on the > tun0 doesn't show anything. So the question is how the packets are supposed to flow from the re(4) to the tun(4); presumably the program listens on re with bpf, grabs packets, munges them somehow, and then writes them to the control side of the tun. Probably time to fire up a debugger and trace a packet. > The software is supposed to work on NetBSD (as FreeBSD and OpenBSD), > but I can't find any reference to it. I have some working > Linux-Chillispot machines around, and I would like to convert them to > NetBSD and CoovaChilli (maintained, as Chillispot is has been > abandoned in 2006 and has no (real) *BSD support, just some patches).
Attachment:
pgpIe1CqcFrou.pgp
Description: PGP signature