WinXP - มีปัญหาในการแบ่งปันอินเทอร์เน็ตกับโมเด็ม USB 3G ผ่าน ICS


1

ทั้งหมด! ฉันต่อสู้กับกำแพงกับปัญหานี้มาหลายวันแล้วและหวังว่าจะมีคนช่วยได้

ฉันเพิ่งสมัครใช้บริการ webConnect 3G / 4G ของ T-Mobile เพื่อแทนที่การเชื่อมต่อ DSL ที่ช้า (ช้า) ในอพาร์ตเมนต์ของฉัน เป้าหมายคือการวางซิมไว้ในโทรศัพท์เครื่องเก่าของฉันและใช้คุณสมบัติการปล่อยสัญญาณอินเทอร์เน็ตในตัวเพื่อแบ่งปันอินเทอร์เน็ตไปยังคอมพิวเตอร์ส่วนที่เหลือของฉัน ฉันพบอย่างรวดเร็วว่าซิมที่จัดสรรผ่านเว็บเชื่อมต่อไม่ได้ทำงานกับสมาร์ทโฟนทั่วไปดังนั้นฉันจึงถูกบังคับให้ซื้อเราเตอร์ที่รองรับ 4G หรือผูกแล็ปท็อปเครื่องเก่ากับเราเตอร์ไร้สายของฉันและแชร์วิธีนั้น ฉันเลือกอันหลังและมันทำให้ตัวเองภายในของฉันเต็มไปด้วยจิตวิญญาณร้ายในเวลากลางวัน

นี่คือการตั้งค่า:

  • โมเด็ม GSM USB (ผ่านฮับ), โฮสต์ ICS ->
  • 10/100 Mbps Ethernet NIC, ICS "แขก" ->
  • พอร์ต WAN ของเราเตอร์ไร้สาย SMC WGBR14N ของฉันในโหมดบริดจ์ (เช่นจุดเชื่อมต่อไร้สาย)
เป็นการดีที่นี่จะทำให้แล็ปท็อปของฉันเป็นเซิร์ฟเวอร์ DHCP และเกตเวย์อินเทอร์เน็ตด้วย WAP ที่ให้ความคุ้มครองไร้สายทุกคน ฉันสามารถท่องอินเทอร์เน็ตบนโฮสต์แล็ปท็อปได้ดี

อย่างไรก็ตามเมื่อลูกค้าพยายามเชื่อมต่อพวกเขาจะได้รับ IP ที่กำหนด DHCP จากแล็ปท็อปและสามารถใช้อินเทอร์เน็ตได้สองสามนาทีก่อนที่จะตายอย่างสมบูรณ์ หลังจากนั้นเกิดขึ้นพวกเขาจะสามารถเชื่อมโยงกับ WAP และรับที่อยู่ IP ได้อีกครั้ง แต่ไม่สามารถใช้อินเทอร์เน็ตหรือแก้ไขที่อยู่ IP จนกว่าจะรีสตาร์ทแล็ปท็อปและเราเตอร์ ถ้าพวกเขาทำได้รับการเข้าถึงก็มากช้ามาก หลังจากรัน Wireshark บนเครื่องโฮสต์ปรากฎว่าเป็นเพราะการเชื่อมต่อ TCP ทุกครั้งจะได้รับ RST DNS ดูเหมือนว่าจะทำงาน

ปกติแล้วฉันจะคิดว่าไฟร์วอลล์เป็นตัวการที่นี่ แต่เมื่อมันทิ้งแพ็กเก็ตมันจะทิ้งมันอย่างสมบูรณ์ ความจริงที่ว่าการเชื่อมต่อ TCP กำลังถูก ACK'ed โดยกฎปลายทางที่ออกมา แน่นอนว่าไม่มีบันทึกเหตุการณ์ที่ไม่ได้พูดอะไรเกี่ยวกับสิ่งที่เกิดขึ้น ฉันยังลองปิดการใช้งานการจัดการพลังงานบน NIC ด้วยเพราะนั่นเป็นสาเหตุของปัญหาในอดีต ที่ไม่ได้ช่วยเช่นกัน ในที่สุดฉันก็ปิดการใช้งานขนาดรับตาม Microsoft KB (ที่ใช้กับ Windows Server 2003, SP2) เพื่อประโยชน์ ฉันกำลังคิดว่าจะลองใช้ด้วย NIC อื่น (จะยากไม่ต้องมีอีเทอร์เน็ต NIC สำรองสำหรับแล็ปท็อป) แต่ฉันรู้สึกว่ามันใช้งานไม่ได้

ใครช่วยได้โปรดแนะนำ ฉันขอโทษสำหรับความยาวของโพสต์นี้ ผลงานทั้งหมดชื่นชมมาก!

-Carlos

คำตอบ:


0

มันแย่มากที่สิ่งนี้ไม่ได้รับความสนใจมากนัก แต่จากนั้นอีกครั้งคนทั่วไปมีการเชื่อมต่อแบบเฉพาะแทนที่จะตั้งค่านี้

หลังจากที่เล่นรอบกับมันให้ดีในขณะที่ผมเชื่อว่าในที่สุดก็ ICS เสียพื้นฐาน ดูเหมือนว่าปัญหาที่ใหญ่ที่สุดคือความเสถียรของเซิร์ฟเวอร์ ICS DHCP ในตัว บางครั้ง DHCP จะพยายามทำงาน แต่จะกำหนดเส้นทางคำขอ DHCP ไปยังโฮสติ้ง NIC แทนที่จะให้บริการคำขอ DHCP ด้วยตนเอง ฉันจะได้รับที่อยู่ลิงค์ท้องถิ่นเมื่อเกิดเหตุการณ์นี้ ในบางครั้งเซิร์ฟเวอร์ DHCP จะออกจากการทำงานทั้งหมดโดยให้การร้องขอ DHCP ไม่มีการตอบรับอย่างสมบูรณ์ ฉันคิดว่าปัญหาทั้งสองนี้เกิดขึ้นอย่างต่อเนื่อง แต่ไม่แน่ใจเกินไป

ฉันไม่รู้ว่าทำไมการเชื่อมต่อ TCP เริ่ม RSTing หลังจากผ่านไประยะหนึ่ง ฉันสังเกตเห็นข้อผิดพลาดบางอย่างจาก Tcpip ใน Event Viewer ดังนั้นฉันคิดว่ามันมีส่วนเกี่ยวข้องกับ winsock ที่ได้รับความเสียหาย ตอนนี้ฉันคิดแล้วบางทีปัญหา DHCP ก็เกี่ยวข้องกับเรื่องนั้นเช่นกัน

วิธีเดียวที่ฉันสามารถทำให้สิ่งนี้ทำงานได้อย่างมีเสถียรภาพคือการทำสิ่งต่อไปนี้:

  • การหยุด ICS โดยยกเลิกการแบ่งการเชื่อมต่อของฉันกับโมเด็ม
  • ปิดใช้งานทั้ง NICS
  • การรีเซ็ต winsock โดยใช้ netsh ( netsh winsock reset) ฉันไม่รีบูท
  • เปิดใช้งาน NIC ทั้งสองและในที่สุด
  • เปิดใช้งาน ICS อีกครั้งโดยแบ่งปันการเชื่อมต่อโมเด็มอีกครั้ง

เมื่อคำนึงถึงสิ่งนี้แล้วจะมีวิธีใดบ้างที่จะเปิดใช้งานการบันทึกการทำงานของ winsock เพื่อดูว่าปัญหาพื้นฐานแสดงอยู่ที่นั่นหรือไม่?

เมื่อรวมกับทุกสิ่งที่ฉันทำฉันไม่ทราบเลยว่าจะใช้งานได้นานแค่ไหน หวังว่ามันจะทำงานได้นานพอที่จะตั้งค่าให้ฉันจนกว่าฉันจะได้รับโมเด็ม Cradlepoint ที่ฉันซื้อ

หวังว่านี่จะช่วยใครซักคน!


อัปเดต: ใช้งานได้เพียงไม่กี่ชั่วโมง ลูกค้าไม่เพียงลดลงหลังจากที่ฉันตื่นเช้านี้คอมพิวเตอร์ก็ใช้งานไม่ได้ ฉันไม่สามารถเริ่มตัวจัดการงานได้และไม่สามารถปิดเครื่องได้อย่างสมบูรณ์ อย่างที่ฉันคาดไว้มันใช้งานได้ดีหลังจากรีสตาร์ท
Carlos Nunez

0

ICS ใช้ช่วง IP แบบคงที่ 192.168.1.0/24 ถ้าฉันไม่ผิด (อาจเป็นได้) ตรวจสอบให้แน่ใจว่าสิ่งนี้ไม่ขัดแย้งกับ IP / ซับเน็ตใน SMC WGBR14N ของคุณ

อาจเป็นไปได้ว่าโมเด็ม 4G ของคุณอาจตรวจพบ TTL ของทราฟฟิกขาออกและยุติการเชื่อมต่อหรือวางเซสชัน PPP ในที่สุดหาก TTL ไม่ใช่สิ่งที่น่าสงสัยนี่เป็นวิธีการค้นพบว่าทราฟฟิกนั้นมาจากระบบที่เชื่อมต่อหรือ "ข้างหลังมัน.


ฉันคิดว่า subnet ของเราเตอร์ไม่เกี่ยวข้องที่นี่เนื่องจากเราเตอร์ทำงานในโหมด AP แต่การตรวจจับ TTL เป็นไปได้แน่นอน @Carlos Nunez คุณสามารถลองใช้พร็อกซี HTTP ในคอมพิวเตอร์ "host" ของคุณแทนและหากใช้งานได้คุณต้องเปลี่ยน TTL เริ่มต้นในคอมพิวเตอร์ "guest" โปรดทราบว่า NAT ยังคงสามารถตรวจจับได้เนื่องจากวิธีหมายเลขลำดับ TCP ในบางระบบ แต่เทคนิคนั้นใช้น้อยกว่า
billc.cn
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.