bugzilla-daemon@netfilter.org
2003-Mar-29 08:45 UTC
[Bug 70] udp connection(snmp) not being tracked.
https://bugzilla.netfilter.org/cgi-bin/bugzilla/show_bug.cgi?id=70 laforge@netfilter.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID Summary|udp connection(snmp) not |udp connection(snmp) not |being tracked. |being tracked. ------- Additional Comments From laforge@netfilter.org 2003-03-29 09:45 ------->From what I understand while reading your bugreport, this is not a netfilterissue. If you have applications (or your routing/...) configured in a way that reply packets are sent from a different IP than the original request packets had been sent to, there is _no way_ that conntrack will catch this. In fact, I think even most clients will not work - since they expect a reply from the address that they've sent something to. (depending on whether they use connect(2) on a SOCK_DGRAM socket). Please reopen this bug if you think that I misunderstood your problem. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
Possibly Parallel Threads
- [Bug 70] New: udp connection(snmp) not being tracked.
- [ANNOUNCE] Security Advisory about IRC DCC connection tracking
- [Bug 48] conntrack breaks udp path mtu discovery
- [Bug 471] New: UDP stream DNAT problem
- [Bug 495] New: Netfilter Connection Tracking Race Condition in Kernel 2.4.x