Hello, Nicholas Couchman a écrit : > > Well, I think I've found part of the problem. The > nf_conntrack_netbios_ns module only operates on port 137, not on port > 138. I don't know exactly what the difference is, but it seems that all > my WINS queries are attempting to go across on port 138. Port 137 is NetBios Name Service. Port 138 is NetBios Datagram Service. WINS is supposed to be Microsoft's implementation of Netbios Name Service, so I am a bit surprised that WINS queries are sent on port 138. [...] > As far as the nf_conntrack_nat_netbios_ns module goes, no, it doesn't > exist in the kernel, If it were to exist it would be named ip_nat_netbios_ns, not nf_conntrack_nat_netbios_ns. But IIUC the nf_conntrack_netbios_ns helper module was specifically designed to handle replies to broadcast NBNS queries, as the generic UDP conntrack handles only unicast, not broadcast (the unicast source address in the reply does not match the broadcast destination address in the query). There would be no point in a NAT helper module. > but I don't see any nf_conntrack_nat* modules their, either, > so I'm thinking that the standard nf_conntrack modules are supposed to > cover NAT No, there are dedicated NAT helper modules. Search for nf_nat_* instead. > in addition to standard routing. s/standard routing/connection tracking/ -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
