- ตอบ
- not spam ()


หลายวันนี้นั่งอ่านโค้ดใหม่ครับ เพิ่งทราบเหมือนกันว่า iptables ที่ให้ download นั้นเป็นเหมือน interface เอง ไม่ใช่ core ของ iptables ดังนั้นที่ผมอ่านมายังใช้ประโยชน์ไม่ได้ในตอนนี้ ตอนนี้ก็เลยต้องหันกลับไปที่ kernel-source แทน
อยากถามเพิ่มเลยครับ ว่า
/usr/src/linux-source-2.6.20/net/netfilter/ กับ
/usr/src/linux-source-2.6.20/net/ipv4/netfilter/
ต่างกันยังไงอ่ะครับ
แต่ผมกลับมาแกะที่ /usr/src/linux-source-2.6.20/net/ipv4/netfilter/
ครับ

สองที่นี้ ต่อไปจะเริ่มต่างกันมากครับ ที่เริ่มแยกก็เพราะปูทางไปสู่การ Support IPv6 ครับ (และ Version ต่อๆ ไปที่อาจจะมีขึ้นได้อีกในอนาคต) เดิมเลยไม่มีใครทันคิดว่า TCP/IP จะมี Version แตกต่อไปอีก คิดว่าน่าจะเป็น Protocol ใหม่ไปเลย ดังนั้นตอนนี้จึงเริ่มจากแก้ไขโครงสร้างของ Source และ Code link location ก่อน จึงเห็นเหมือนๆ กัน (2.6.x แรกๆ เป็น Symbolic link เอาเลยด้วย) ส่วนตัวผม "คาดว่า" Kernel 2.7 น่าจะไม่มี */net/netfilter แล้ว แต่จะเป็น /net/ipv4/netfilter และ /net/ipv6/netfilter แล้วล่ะครับ
Code ที่ 2.6.20 น่าจะยังไม่ต่างกันนะครับ (ยังไม่ได้ไปดูครับ) มันควรจะต้องเหมือนกัน (ถ้าไม่เหมือน ผมก็สงสัยเหมือนกัน ว่าทำไม? หรือ Linus จะเอา IPv6 เป็น Default ในอนาคตแทน IPv4... อืมม์ๆ เดี๋ยวดูลูกน้องที่พอว่างซักคนให้ติดตามเรื่องนี้มารายงานหน่อยดีกว่า)
อีกเรื่องคือ iptables นั้น ในสายตาผม ผมมองเหมือน Rule เท่านั้นเองครับ ประมาณ "จราจร" แต่ไม่ใช่ "ผู้คุมกฏ" แต่ Core อยู่ที่ Kernel อันนี้เข้าใจถูกแล้วครับ

เดี๋ยวพรุ่งนี้ผมจะไล่ดูให้นะครับ เพราะลืมแล้วเหมือนกัน เนื่องจากหลังจาก IPv4 แล้ว ไม่ได้ดูอีกเลย เลยห่างมานานเป็นปีเลย ยามว่างผมมัวไปสนุกอยู่กับ Kernel Hardware module และ ALSA มากกว่าครับ
ฝากข่าวมาบอกทิ้งไว้ที่นี่อีกนิด สำหรับ Chipset VIA ที่แก้ไขไปแล้วนั้น ตกลงยังไม่สมบูรณ์ดีนะครับ ยังมีทิ้ง bug ไว้นิดหน่อย เมื่อเจอกับอุปกรณ์ที่เป็น UDMA 44 เช่น CD-ROM ธรรมดาๆ รุ่นกลางเก่ากลางใหม่ แต่เห็นว่าคงโดนกับกลุ่มคนไม่มากแล้ว ก็เลย เดี๋ยวค่อยแก้แล้วกัน
ตอนนี้ยังเจอปัญหา USB ใหม่อีก (480 Mbit) สนุกดีจริงๆ ครับ
ต่อไปยังมี ACPI V.3 อีก...
แล้วยังมี SATA V.3 ต่อคิวอีก (Hardware ยังไม่ launch แต่ Data sheet ได้มาแล้วครับ)
20/10/2550
ลองไล่ดูแล้วครับ ทราบปัญหาแล้ว ครับ แต่ไม่แน่ใจว่าถูกหรือเปล่า
คือว่า ระบบ Intranet ที่มีเครื่องที่ปล่อย multicast เครื่อง server จะไม่รับ Multicast เลยครับ เพราะว่า ip ไม่ได้มี เป้าหมายมาที่เครื่อง server ครับ ดังนั้นจึงต้องทำให้ server รุ้จักโดยลง multicast routing ให้ server คอย join multicast group ได้ครับ
และเมื่อ server รับ multicast ได้แล้ว มันจะผ่าน packet ไปให้ server ซึ่ง NAT ทำงานอยู่ netfilter ก็จะได้รับครับ และก็จะทำงานผ่านไปทั้ง random port เปลี่ยน source address ของ packet
แต่ว่า !!! เครื่องจะไม่ส่ง packet ออกไปสู่ internet ครับ เนื่องจากที่ผมเข้าใจคือ เครื่อง server เองก็คือปลายทางเหมือนกัน จึงไม่สามารถทำงาน forward ได้ ถามว่า
ผมจะแก้ส่วนไหนดีครับ ถ้าต้องการให้ มี packet multicast ออก ไป สู่ internet ครับ
1 เก็บ packet ลง mem อะไรสักอย่างนึง แล้วเขียน create sock อ่าน mem ออกไปเอง (ไม่รู้ว่า ยากไหมถ้าจะเขียนให้ kernel ส่งเอง จะเขียนไว้ที่ไหนดี หรือว่าควรแก้ที่ไหนดีครับ)
retval = sock_create(PF_INET, SOCK_DGRAM, 0, &sock);
2 ....
21/10/2550
วันนี้ลองเขียนดูแล้วครับ ก็เกิดคำถามสงสัยขึ้นมาว่า
จะเขียนแบบไปแทรกๆ ใน function ของเขาดีหรือว่าเขียนเป็นไฟล์ใหม่ดีครับ เพราะว่าผมเขียนการเขียนแล้วมันจะมี init_funtion name ประมาณว่าเป็น constructer ประมาณนี้
int __init netfilter_init(void)
void __exit netfilter_exit(void)
module_init(netfilter_init);
module_exit(netfilter_exit);
ซึ่งผมก็ยังคง งงๆ กับการทำงานของ kernel อยู่แต่ไม่รู้ว่าถูกหรือเปล่าคือ module_init(netfilter_init); คือการ register กับ kernel ให้ kernel เรียกทำงานเมื่อเปิดเครื่อง (ประมาณนี้) แล้วผมสงสัยว่าจะเรียกใช้งาน function ในไฟล์อย่างไรนอกเหนือจาก init และ exit
คือผมยังเริ่มต้นเขียนไม่ถูกครับ ไม่รู้ว่าจะเริ่มอย่างไรดี ตัวอย่างก็มีให้ดูแล้วครับ แต่คงไม่ 100% ก็การทำงานของ kernel นี่สิ ที่ไม่รุ้จะอ่าน code อย่างไรครับ T-T
ตอนมืดๆ
ลองเขียน packet ลงไฟล์ก่อนครับ ลองเล่นๆ ที่ ipt_LOG.c เขียนไฟล์ต้อง stdlib.h พอ include เข้าไปใช้ไม่ได้ครับ ทั้งๆ ที่ ที่อื่น ใช้ได้ ไม่รู้ว่าทำไมใน /ipv4/netfilter/ ถึงใช้ไม่ได้ งงอีกครั้ง หุหุ (จริงๆ เรียกว่าไม่รู้โครงสร้างมากกว่าไม่งั้นไม่ติดแง็กอย่างนี้หรอก)
ตอบคำถามก่อนหน้านี้ (ถามเองตอบเอง) int __init เป็น macro ครับ ที่เอาไว้บอก compilerว่า function นี้ต้องการทำงานและ compiler จะจอง mem ไว้ให้ครับ (จากหนังสือ linux kernel primer แต่ว่าไม่มีเรื่องเกี่ยวกับ network อ่ะ T-T)
วันนี้ลองใหม่เมื่อเขียนลงไฟล์ไม่ได้ สั่งให้ printk มาเลยแล้วกัน ที่ไหนได้ skbuff ที่นำมาใส่ kernel panic เลย หุหุหุ T-T
คิดว่าเจอไฟล์ที่รับ packet แล้วคือ net/ipv4/ip_input.c กับ ip_output.c ครับ ลอง debug ดู มี ip src และ dst แล้วแต่ว่าหา Payload ไม่เจออ่ะครับ ทำไงดี มันอยู่ที่ไหนอ่ะครับ ดูที่ skbuff ก็ไม่มีหรือว่าผมหาไม่เจอครับ (จากไฟล์ skbuff.h)
* struct sk_buff - socket buffer
* @next: Next buffer in list
* @prev: Previous buffer in list
* @sk: Socket we are owned by
* @tstamp: Time we arrived
* @dev: Device we arrived on/are leaving by
* @input_dev: Device we arrived on
* @h: Transport layer header
* @nh: Network layer header
* @mac: Link layer header
* @dst: destination entry
* @sp: the security path, used for xfrm
* @cb: Control buffer. Free for use by every layer. Put private vars here
* @len: Length of actual data
* @data_len: Data length
* @mac_len: Length of link layer header
* @csum: Checksum
* @local_df: allow local fragmentation
* @cloned: Head may be cloned (check refcnt to be sure)
* @nohdr: Payload reference only, must not modify header
* @pkt_type: Packet class
* @fclone: skbuff clone status
* @ip_summed: Driver fed us an IP checksum
* @priority: Packet queueing priority
* @users: User count - see {datagram,tcp}.c
* @protocol: Packet protocol from driver
* @truesize: Buffer size
* @head: Head of buffer
* @data: Data head pointer
* @tail: Tail pointer
* @end: End pointer
* @destructor: Destruct function
* @mark: Generic packet mark
* @nfct: Associated connection, if any
* @ipvs_property: skbuff is owned by ipvs
* @nfctinfo: Relationship of this skb to the connection
* @nfct_reasm: netfilter conntrack re-assembly pointer
* @nf_bridge: Saved data about a bridged frame - see br_netfilter.c
* @tc_index: Traffic control index
* @tc_verd: traffic control verdict
* @dma_cookie: a cookie to one of several possible DMA operations
* done by skb DMA functions
* @secmark: security marking


สวัสดีครับ ผมขอภัยที่นอกเรื่องหน่อยนะครับ คือผมทำโปคเจค เรื่อง hotspot ครับ แล้วผมก็มีความรู้เกี่ยวกับ linux ซึ่งถือว่าน้อยมาก แล้วมีเรื่องสงสัยเกี่ยวกับการควบคุมแบนวิช อยากจะถามพี่ๆน่ะครับ
ผมใช้ เครื่อง PC 1 เครื่อง เป็น server OS:fedara core3 ที่ใช้จัดการ โดยลง webserver ,freeradius,Chillispot(เป็นโปรแกรมจัดการการเข้าใช้งาน)
การทำงานโดยรวมคือ
1.ผู้เข้าใช้ระบบ hotspot ในการเล่นอินเตอร์เนตจะได้รับ ip จาก chillispot ซึ่งเป็นตัวแจก ip ให้
2.เมื่อต้องการเล่นอินเตอร์เนตโดยเปิดบราวเซอร์ขึ้นมา chillispot จะทำการ redirect หน้า login มากให้ผุ้ใช้กรอก username password
3.นำ username password ไปตรวจสอบกับ freeradius ถ้า username password ถูกต้อง freeradius ก็จะส่งเพ๊กเกจสิทธิต่างๆ เช่น แบนวิชที่ได้รับอนุญาติให้ใช้ในการอัพโหลด/ดาวน์โหลด โดยข้อมูลสิทธินี้ freeradius จะส่งมาให้กับ chillispot เพื่อควบคุมให้ client ได้ทำงานตามนั้น
คือว่าตอนไปสอบโปรเจคน่ะครับ อาจารย์ถามรายละเอียดว่า
1. chillispot ทำการควบคุม bandwidth ของแต่ละ ipหรือแต่ละยูสเซอร์ อย่างไร (จริงๆแล้วอะไรเป็นตัวควบคุมแบนด์วิชนี้และทำงานอย่างไร) ผมตอบกับอาจารย์ไม่ได้
ผมอยากจะถามพี่ๆว่า
-ถ้าโปรแกรม chillispot เองเป็นตัวควบคุมแบนด์วิช แล้วมันควบคุมได้อย่างไรหรอครับ
-หรือถ้าไม่ใช่ chillispot เป็นตัวควบคุมแล้วมันสร้างกฏไว้ที่ไหนเพื่อจำกัดแบนวิชนี้ เช่น netfilter รึป่าวครับ และสามารถตรวจสอบได้อย่างไร
2. อยากทราบความสัมพันธ์ของระหว่างการทำงานของโปรแกรม chillispot กับ การแจก ip ให้กับเครื่อง client (chillispot เป็นตัวแจก ip เอง) โดยมีข้อสังเกตุว่าทำไมไม่ใช้ dhcp server ต่างหากเป็นตัวแจก
(ผมหาข้อมูลจากเวปของ chillispot "www.chillispot.info" แล้วมันไม่มีข้อมูลเชิงเทคนิคลึกๆเลยน่ะครับก็เลยไม่รู้จะได้ข้อมูลอย่างไร และจริงๆแล้วผมควรจะต้องแกะ code ของโปรแกรมดู แต่ว่าผมแกะไม่เป็นน่ะครับไม่รู้ว่าจะเริ่มยังไง แล้วก็เหลือเวลาน้อยมากครับ ขอความกรุณาพี่ๆ ช่วยตอบคำถาม หรือว่า มีแหล่งข้อมูลที่เกี่ยวข้องช่วยส่งให้หน่อยครับ)
ขอบคุณมากๆเลยครับ (i_icejung@hotmail.com)
ตอบ อ่าน feature ของ พริก (chillispot) แล้วนะครับ มันไม่ได้เป็นตัวคุม BW นี่ ตัว freeradius ต่างหาก
ส่วนวิธีการคุม BW เขาก็อ้าง RFC (2548 มั้ง) ยังไงคงต้องอ่านวิธีจัดการ BW แล้วอ่ะ
http://www.freeradius.org/rfc/draft-ietf-radius-ms-ba-attr-01.txt
ส่วนข้อสองนี่ไม่รู้แฮะ ถ้าให้เดานะแจกเองง่ายกว่าตัว sw อาจจะรับ ip มา แต่ว่าตอนแจกนี่แจกเองคงเขียนควบคุมง่ายกว่า (ความเห็นส่วนตัวนะ)
กำลังมอดแล้วครับ เพราะไม่รู้จะไปต่ออย่างไร คงต้องเริ่มไล่ (แต่ก็ไม่รู้จะเริ่มตรงไหนดีหุหุหุ)
ที่เขียนไป ก็อยากให้รู้ว่าทำอะไรไปบ้างจะได้ตอบครั้งเดียวได้ถูกครับ ไม่เสียเวลามาเปิดอ่านแล้วผมกลับมาถามไป ถามมาอีก จริงๆ อยากเขียนให้เข้าใจทีเดียวเหมือนกันแต่ว่าเป็นอะไรที่อธิบายไม่ถูก
อ้อ อ่านๆ ไปได้แนวคิดใหม่ขึ้นมาด้วยคือว่า
อยากแก้ไข kernel ให้เห็น multicast ที่รับเข้ามากลายเป็น packet ที่ต้องส่งออกไป แต่ควรจะทำอย่างไรดี(มีคำถาม)
1. ต้องการรู้ว่า Local packet ที่ส่งออกไปนอกเครื่องแตกต่างจาก packet ที่ต้อง forward อย่างไร
2. ถ้าไม่มี host ปลายมีแต่ ip ปลายทาง แล้วเครื่อง server ก็ไม่รู้จัก server จะส่ง packet นี้ออกไปหรือไม่
(ส่วน bug เรื่อง sis อ่านดูแล้ว จะรีบแก้โดยด่วน)
สวัสดีครับ ทุกๆ ท่านวันนี้ผมมีปัญหาอยากถามครับ ซึ่งเป็นปัญหาที่ยังหาทางแก้ไม่ได้ครับ (อาจจะขอถามพิเศษกับคุณ จักรนันท์ ด้วยครับ)
คือ อยากถามว่า
1. ไม่ทราบว่า iptables นั้นสามารถที่จะ forward multicast ได้หรือไม่ครับ ได้ลองทดสอบกับ access grid(AG) โดยตั้ง AG server ไว้วงเดียวกับ server ที่ใช้ iptables แล้วเปิดใช้งาน NAT มีเครื่อง client อยู่ใด้ NAT 1 ตัว แล้วก็มี ethereal คอยดู packet ที่วิ่ง ปรากฎว่าไม่สามารถใช้ได้ครับเนื่องจาก multicast packet ไม่ถูกส่งผ่าน nat server สังเกตจาก ethereal ครับ
2. หรือว่า การที่จะทำให้สามารถใช้งานได้ต้องมี module หรือเปิด อะไรเพิ่มเติม
3. ถ้าต้อง hack code ของ iptables ก็กำลังลองแต่ติดปัญหาที่ว่า kernel เป็นตัวเรียกใช้ iptables ก็เลยต้อง hack kernel source ด้วย แต่ว่าเยอะเหลือเกินไม่รู้จะเริ่มจากตรงไหน ตอนนี้ดูอยู่ตรง /usr/src/linux-source-2.6.20/include/net/ แต่ก็ยังเยอะอยู่ดี ถามพิเศษคุณจักรนันท์ด้วยครับ ว่าช่วยแนะนำได้ไหมครับ พยายามจะหาตรงส่วนของ kernel เมื่อได้รับ packet จาก physical layer แล้วมันส่งไปเรียก iptables อย่างไร คือต้องการที่จะหาจุดเริ่มต้น (ที่ kernel เรียก iptables ถ้ารู้ว่า kernel function ไหนเรียก แล้วเรียก function ไหนของ iptables เลยก็ดีครับ แต่ถ้าไม่ได้ก็ไม่เป็นไร) ครับ ไล่ไม่ถูกเพิ่งหัดแกะโปรแกรมขนาดใหญ่ก็คราวนี้เอง ขอบคุณทุกท่านครับ