मुझे लगता है कि कारण है दूसरा आईपी टुकड़ा यूडीपी हैडर (मुझे लगता है कि टीसीपी के लिए एक ही है), इसलिए libpcap फिल्टर UDP पोर्ट व्यक्त का उपयोग कर उन्हें कब्जा नहीं कर सकते हैं के साथ नहीं हैं 20000.
हां, यह सही है।
आप udp port 20000 or (ip[6:2] & 0x1fff) != 0
को आजमा सकते हैं, जो पहले 200 से और आईपी टुकड़े पहले खंड के अलावा पैकेट को कैप्चर करेगा; यह आदर्श नहीं है, लेकिन यह सब कुछ है जो आप libpcap फ़िल्टर के साथ कर सकते हैं, यह देखते हुए कि फ़िल्टर तंत्र जो यह उपयोग करता है (जो ओएस कर्नेल का हिस्सा है) पैकेट के बीच कोई इतिहास नहीं रखता है, और इसलिए यह जानने का कोई तरीका नहीं है कि एक पैकेट दिया गया आईपी आईडी एक ही आईपी आईडी के साथ एक और पैकेट, 0 का एक खंड ऑफसेट, और पोर्ट 20000 के साथ एक यूडीपी हेडर के रूप में एक ही खंड का हिस्सा होता है।
(ध्यान दें कि लिनक्स के कम से कम कुछ संस्करण संचारित होंगे में एक आईपी डेटाग्राम के टुकड़े रिवर्स ऑर्डर - प्राप्तकर्ता को अंतिम टुकड़ा पहले देखने की अनुमति देने के लिए, और इस प्रकार पुन: एकत्रित पैकेट के आकार का अधिक सटीक अनुमान लगाने में सक्षम होने के लिए। इससे यह भी और मुश्किल हो जाएगा जांचने वाले फ़िल्टर के साथ आईपी पैकेट के सभी टुकड़ों को कैप्चर करने के लिए टीसीपी या यूडीपी हेडर में फ़ील्ड।)
स्रोत
2013-11-07 12:18:12
यदि कोई यूडीपी पैकेट खंडित होता है और टुकड़े उनके स्रोत/गंतव्य की पहचान नहीं करते हैं, तो ज़ीउस के बटथोल के नाम पर वे उचित होस्ट और एप्लिकेशन पर कैसे जाते हैं? –
दूसरा खंड आईपी हेडर के साथ है लेकिन कोई यूडीपी हेडर नहीं है। आईपी / टीसीपी स्टैक पहले यूडीपी पैकेट को एप्लिकेशन में वितरित करने से पहले पहले और दूसरे आईपी खंड को असेंबली करेगा। लेकिन मुझे ऐसा लगता है कि libpcap दूसरे आईपी टुकड़े को पहचान नहीं सकता है। – misteryes
एक टीसीपी/आईपी स्टैक कैसे पता चलेगा कि दूसरा खंड उसी सॉकेट से संबंधित है जो पहले यूडीपी हेडर के बिना है? हो सकता है कि आपको खुद को पुन: सामान करना होगा - जो वास्तव में मुश्किल नहीं होना चाहिए। –