Volunteer opportunity for Networking tasks
Dear all, I am interested in contributing to the networking tasks of the FreeBSD project. Having been on the freebsd-net mailing-list for about 6 months now (and freebsd-current more recently), I really want to make myself useful, and provide help in completing tasks on networking or wireless networking areas. I had been on the Networking Wikipage (this one : http://wiki.freebsd.org/Networking), which describes the current on-going tasks, I had been working over the last 2 weeks on rewriting some parts of netstat(1) (mainly the part dumping the routing table) to make it use sysctl rather than kvm. However after reading Mr.Gerzo's mail about the FreeBSD Status Reports from yesterday evening, which talked about libnetstat(), I'm starting to wonder whether whatever work I've done so far is actually worthwhile... I was thinking of getting some experience on board before volunteering for further work. There are a good few tasks mentionned on the Networking Wikipage that interest me a lot, so I'll just start working on something else if that work is no longer required for netstat :-). Please make me aware of any opportunities or tasks in which there is a need for more people, I'd be greatly honoured to provide help. -- Aman Jassal ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Current problem reports assigned to freebsd-net@FreeBSD.org
Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description o kern/139387 net[ipsec] Wrong lenth of PF_KEY messages in promiscuous o bin/139346 net[patch] arp(8) add option to remove static entries lis o kern/139268 net[if_bridge] [patch] allow if_bridge to forward just VL o kern/139204 net[arp] DHCP server replies rejected, ARP entry lost bef o kern/139162 net[fwip] [panic] 8.0-RC1 panics if using IP over firewir o kern/139145 net[ip6] IPv6 blackhole / reject routes broken o kern/139117 net[lagg] + wlan boot timing (EBUSY) o kern/139113 net[arp] removing IP alias doesn't delete permanent arp e o kern/139058 net[ipfilter] mbuf cluster leak on FreeBSD 7.2 o kern/138999 net[libc] lighttpd/php-cgi with freebsd sendfile(2) enabl o kern/138850 net[dummynet] dummynet doesn't work correctly on a bridge o kern/138782 net[panic] sbflush_internal: cc 0 || mb 0xff004127b00 o kern/138739 net[wpi] wpi(4) does not work very well under 8.0-BETA4 o kern/138694 net[bge] FreeBSD 6.3 release does not recognize Broadcom o amd64/138688 net[rum] possibly broken on 8 Beta 4 amd64: able to wpa a o kern/138678 net[lo] FreeBSD does not assign linklocal address to loop o kern/138676 net[route] after buildworld not work local routes [regres f kern/138666 net[multicast] [panic] not working multicast through igmp o kern/138660 net[igb] igb driver troubles in 8.0-BETA4 o kern/138652 netTCP window scaling value calculated incorrectly? o kern/138620 net[lagg] [patch] lagg port bpf-writes blocked o kern/138427 net[wpi] [panic] Kernel panic after trying set monitor wl o kern/138407 net[gre] gre(4) interface does not come up after reboot o kern/138390 net[gif] [patch] NULL pointer dereference in gif_input() o kern/138378 net[altq] [patch] Memory leak in hfsc_class_modify() in f o kern/138332 net[tun] [lor] ifconfig tun0 destroy causes LOR on 8.0-BE o kern/138266 net[panic] kernel panic when udp benchmark test used as r o kern/138177 net[ipfilter] FreeBSD crashing repeatedly in ip_nat.c:257 o kern/138130 net[netinet] [patch] Resource leak in LibAliasRefreshModu o kern/138046 net[tcp] tcp sockets stay in SYN_SENT even after receivin o kern/137881 net[netgraph] [panic] ng_pppoe fatal trap 12 o bin/137841 net[patch] wpa_supplicant(8) cannot verify SHA256 signed p kern/137795 net[sctp] [panic] mtx_lock() of destroyed mutex o kern/137776 net[rum] panic in rum(4) driver on 8.0-BETA2 o kern/137775 net[netgraph] [patch] Add XMIT_FAILOVER to ng_one2many o bin/137641 netifconfig(8): various problems with "vlan_device.vlan_i o kern/137592 net[ath] panic - 7-STABLE (Aug 7, 2009 UTC) crashes on ne o bin/137484 net[patch] Integer overflow in wpa_supplicant(8) base64 e o kern/137392 net[ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net[ral] FreeBSD doesn't support wireless interface from o kern/137317 net[tcp] logs full of syncache problems o kern/137292 net[ste] DFE-580TX not working properly o kern/137279 net[bge] [panic] Page fault (fatal trap 12) NFS server w/ o kern/137089 net[lagg] lagg falsely triggers IPv6 duplicate address de o bin/136994 net[patch] ifconfig(8) print carp mac address o kern/136943 net[wpi] [lor] wpi0_com_lock / wpi0 o kern/136911 net[netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136876 net[bge] bge will not resume properly after suspend o kern/136836 net[ath] atheros card stops functioning after about 12 ho o kern/136618 net[pf][stf] panic on cloning interface without unit numb o kern/136482 net[age] Attansic L1 Gigabit Ethernet recieves multicasts o kern/136426 net[panic] spawning several dhclients in parallel panics o kern/136168 net[em] em driver initialization fails on Intel 5000PSL m o kern/135836 net[bce] bce BCM5709 Watchdog after warm boot - ok after o kern/135502 net[periodic] Warning message raised by rtfree function i o kern/135222 net[igb] low speed routing between two igb interfaces o kern/135067 net[patch] [fib] Incorrect KASSERTs in sys/net/route.c o kern/134956 net[em] FreeBSD 7.1 & 7.2, Intel PRO/1000 PT Quad Port Se o kern/134931 net[route] [fib] Route messages sent to all socket listen o kern/134658 net[bce
Re: Page fault in IFNET_WLOCK_ASSERT [if.c and pccbb.c]
On 12 Oct 2009, at 05:38, Harsha wrote: Thanks a lot for the clarification. I had assumed that the lock was non-sleepable looking at this log - Kernel page fault with the following non-sleepable locks held: exclusive rw ifnet_rw (ifnet_rw) r = 0 (0xc0f63464) locked @ /usr/src/sys/net/if.c:409 Looks like a NULL pointer dereference, so perhaps a more traditional bug -- could you convert ifindex_alloc_locked+0x71 to a line of code? You can do this using kgdb on the kernel symbols file, perhaps "l *ifindex_alloc_locked+0x71". Robert ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
ARP changes
I know that arp has changed a lot in FreeBSD 8. I am wondering if one change was by design? In older versions of FreeBSD, if you ping a host that is on a local network but is down, after a few seconds ping displays: ping: sendto: Host is down ping: sendto: Host is down Using arp to display the arp table shows: host.domain (x.x.x.x) at (incomplete) on em0 [ethernet] In FreeBSD 8, the incomplete arp entries don't show up. Ping never prints "Host is down'. The old behaviors can useful when trouble shooting local network problems. Is there a reason for the changes? -- Larry Baird| http://www.gta.com Global Technology Associates, Inc. | Orlando, FL Email: l...@gta.com | TEL 407-380-0220, FAX 407-380-6080 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
RE: ARP changes
Might be a regression issue. I will take a look and get back to you later today. -- Qing > -Original Message- > From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd- > n...@freebsd.org] On Behalf Of Larry Baird > Sent: Monday, October 12, 2009 7:42 AM > To: freebsd-net@freebsd.org > Subject: ARP changes > > I know that arp has changed a lot in FreeBSD 8. I am wondering if one > change was by design? In older versions of FreeBSD, if you ping a host > that is on a local network but is down, after a few seconds ping > displays: > ping: sendto: Host is down > ping: sendto: Host is down > > Using arp to display the arp table shows: > host.domain (x.x.x.x) at (incomplete) on em0 [ethernet] > > In FreeBSD 8, the incomplete arp entries don't show up. Ping never > prints "Host is down'. The old behaviors can useful when trouble > shooting local network problems. Is there a reason for the changes? > > > -- > --- > - > Larry Baird| http://www.gta.com > Global Technology Associates, Inc. | Orlando, FL > Email: l...@gta.com | TEL 407-380-0220, FAX 407-380-6080 > ___ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
RE: ARP changes
At 01:05 PM 10/12/2009, Li, Qing wrote: Might be a regression issue. I will take a look and get back to you later today. Actually, the behaviour is different on RELENG_6, RELENG_7 and RELENG_8. On RELENG_6, the negative entry is cached for some, on RELENG_7, less than 1 second and on RELENG_8, it never shows up at all ---Mike Mike Tancsa, tel +1 519 651 3400 Sentex Communications,m...@sentex.net Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/116328: [bge]: Solid hang with bge interface
Synopsis: [bge]: Solid hang with bge interface Responsible-Changed-From-To: freebsd-net->bz Responsible-Changed-By: bz Responsible-Changed-When: Mon Oct 12 21:56:26 UTC 2009 Responsible-Changed-Why: Take for the moment. http://www.freebsd.org/cgi/query-pr.cgi?pr=116328 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/122252: [ipmi] [bge] IPMI problem with BCM5704 (does not work after driver loaded)
Synopsis: [ipmi] [bge] IPMI problem with BCM5704 (does not work after driver loaded) Responsible-Changed-From-To: freebsd-net->bz Responsible-Changed-By: bz Responsible-Changed-When: Mon Oct 12 21:57:02 UTC 2009 Responsible-Changed-Why: Take for the moment. http://www.freebsd.org/cgi/query-pr.cgi?pr=122252 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Wacky DHCP values that work in windows but not in FreeBSD
Howdy, I usually have a wireless router connected directly to the AT&T/Yahoo DSL modem but last night I wanted to do some debugging so I plugged my laptop directly into the modem (after powering off the modem, etc.). The values I got back from DHCP not only don't make sense, they didn't work in FreeBSD at all. Dual-booting to Windows showed that the values I saw from DHCP were "correct," and somehow they managed to work. Taking a closer look at the router after I plugged it back in showed the same. Dhcp Enabled. . . . . . . . . . . : Yes Autoconfiguration Enabled . . . . : Yes IP Address. . . . . . . . . . . . : 76.212.147.xxx Subnet Mask . . . . . . . . . . . : 255.255.0.0 Default Gateway . . . . . . . . . : 151.164.184.xxx DHCP Server . . . . . . . . . . . : 192.168.1.xxx DNS Servers . . . . . . . . . . . : 192.168.1.xxx Can anyone tell me how they managed to get this to work in Windows, and suggest where to look to get it working in FreeBSD? Doug -- Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Wacky DHCP values that work in windows but not in FreeBSD
Doug Barton wrote: Howdy, I usually have a wireless router connected directly to the AT&T/Yahoo DSL modem but last night I wanted to do some debugging so I plugged my laptop directly into the modem (after powering off the modem, etc.). The values I got back from DHCP not only don't make sense, they didn't work in FreeBSD at all. Dual-booting to Windows showed that the values I saw from DHCP were "correct," and somehow they managed to work. Taking a closer look at the router after I plugged it back in showed the same. Dhcp Enabled. . . . . . . . . . . : Yes Autoconfiguration Enabled . . . . : Yes IP Address. . . . . . . . . . . . : 76.212.147.xxx Subnet Mask . . . . . . . . . . . : 255.255.0.0 Default Gateway . . . . . . . . . : 151.164.184.xxx huh? only way this could work would be if it was marked as "point to point" I think.. DHCP Server . . . . . . . . . . . : 192.168.1.xxx DNS Servers . . . . . . . . . . . : 192.168.1.xxx Can anyone tell me how they managed to get this to work in Windows, and suggest where to look to get it working in FreeBSD? Doug ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
RE: Wacky DHCP values that work in windows but not in FreeBSD
> -Original Message- > From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd- > n...@freebsd.org] On Behalf Of Julian Elischer > Sent: Monday, October 12, 2009 4:00 PM > To: Doug Barton > Cc: freebsd-net@freebsd.org > Subject: Re: Wacky DHCP values that work in windows but not in FreeBSD > > Doug Barton wrote: > > Howdy, > > > > I usually have a wireless router connected directly to the AT&T/Yahoo > > DSL modem but last night I wanted to do some debugging so I plugged > my > > laptop directly into the modem (after powering off the modem, etc.). > > > > The values I got back from DHCP not only don't make sense, they > didn't > > work in FreeBSD at all. Dual-booting to Windows showed that the > values > > I saw from DHCP were "correct," and somehow they managed to work. > > Taking a closer look at the router after I plugged it back in showed > > the same. > > > > Dhcp Enabled. . . . . . . . . . . : Yes > > Autoconfiguration Enabled . . . . : Yes > > IP Address. . . . . . . . . . . . : 76.212.147.xxx > > Subnet Mask . . . . . . . . . . . : 255.255.0.0 > > Default Gateway . . . . . . . . . : 151.164.184.xxx > > huh? > > only way this could work would be if it was marked as "point to point" > I think.. That could be a primary IP address on an interface on which your 76 address is a sub interface. The interface will do proxy-arp when a traffic request comes in. Or something else! I'm not sure if this will work, but you could actually hard code your default gateway with a -hopcount 2 (or higher) and see if that works. I've not tried it on a live machine. Something like route add default 151.164.184.xxx -hopcount 5. You may have to delete the DHCP-assigned entry first. Regards, Mike ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Wacky DHCP values that work in windows but not in FreeBSD
Michael K. Smith - Adhost wrote: >> -Original Message- >> From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd- >> n...@freebsd.org] On Behalf Of Julian Elischer >> Sent: Monday, October 12, 2009 4:00 PM >> To: Doug Barton >> Cc: freebsd-net@freebsd.org >> Subject: Re: Wacky DHCP values that work in windows but not in FreeBSD >> >> Doug Barton wrote: >>> Howdy, >>> >>> I usually have a wireless router connected directly to the > AT&T/Yahoo >>> DSL modem but last night I wanted to do some debugging so I plugged >> my >>> laptop directly into the modem (after powering off the modem, etc.). >>> >>> The values I got back from DHCP not only don't make sense, they >> didn't >>> work in FreeBSD at all. Dual-booting to Windows showed that the >> values >>> I saw from DHCP were "correct," and somehow they managed to work. >>> Taking a closer look at the router after I plugged it back in showed >>> the same. >>> >>> Dhcp Enabled. . . . . . . . . . . : Yes >>> Autoconfiguration Enabled . . . . : Yes >>> IP Address. . . . . . . . . . . . : 76.212.147.xxx >>> Subnet Mask . . . . . . . . . . . : 255.255.0.0 >>> Default Gateway . . . . . . . . . : 151.164.184.xxx >> huh? >> >> only way this could work would be if it was marked as "point to point" >> I think.. > > That could be a primary IP address on an interface on which your 76 > address is a sub interface. Can you specify what you mean by 'that'? > The interface will do proxy-arp when a > traffic request comes in. Or something else! I'm not sure if this will > work, but you could actually hard code your default gateway with a > -hopcount 2 (or higher) and see if that works. I've not tried it on a > live machine. Something like route add default 151.164.184.xxx > -hopcount 5. You may have to delete the DHCP-assigned entry first. Ah, I didn't know about -hopcount, thanks. There was no default route installed at all when I booted. I tried 'route add default 151...' even though I was sure it wouldn't work, and I was not disappointed. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Wacky DHCP values that work in windows but not in FreeBSD
Doug Barton wrote: Michael K. Smith - Adhost wrote: -Original Message- From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd- n...@freebsd.org] On Behalf Of Julian Elischer Sent: Monday, October 12, 2009 4:00 PM To: Doug Barton Cc: freebsd-net@freebsd.org Subject: Re: Wacky DHCP values that work in windows but not in FreeBSD Doug Barton wrote: Howdy, I usually have a wireless router connected directly to the AT&T/Yahoo DSL modem but last night I wanted to do some debugging so I plugged my laptop directly into the modem (after powering off the modem, etc.). The values I got back from DHCP not only don't make sense, they didn't work in FreeBSD at all. Dual-booting to Windows showed that the values I saw from DHCP were "correct," and somehow they managed to work. Taking a closer look at the router after I plugged it back in showed the same. Dhcp Enabled. . . . . . . . . . . : Yes Autoconfiguration Enabled . . . . : Yes IP Address. . . . . . . . . . . . : 76.212.147.xxx Subnet Mask . . . . . . . . . . . : 255.255.0.0 Default Gateway . . . . . . . . . : 151.164.184.xxx huh? only way this could work would be if it was marked as "point to point" I think.. That could be a primary IP address on an interface on which your 76 address is a sub interface. Can you specify what you mean by 'that'? The interface will do proxy-arp when a traffic request comes in. Or something else! I'm not sure if this will work, but you could actually hard code your default gateway with a -hopcount 2 (or higher) and see if that works. I've not tried it on a live machine. Something like route add default 151.164.184.xxx -hopcount 5. You may have to delete the DHCP-assigned entry first. Ah, I didn't know about -hopcount, thanks. There was no default route installed at all when I booted. I tried 'route add default 151...' even though I was sure it wouldn't work, and I was not disappointed. Doug also not sure if you can add a -iface argument to make your default route include the correct interface . ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Wacky DHCP values that work in windows but not in FreeBSD
Julian Elischer wrote: > Doug Barton wrote: >> Howdy, >> >> I usually have a wireless router connected directly to the AT&T/Yahoo >> DSL modem but last night I wanted to do some debugging so I plugged my >> laptop directly into the modem (after powering off the modem, etc.). >> >> The values I got back from DHCP not only don't make sense, they didn't >> work in FreeBSD at all. Dual-booting to Windows showed that the values >> I saw from DHCP were "correct," and somehow they managed to work. >> Taking a closer look at the router after I plugged it back in showed >> the same. >> >> Dhcp Enabled. . . . . . . . . . . : Yes >> Autoconfiguration Enabled . . . . : Yes >> IP Address. . . . . . . . . . . . : 76.212.147.xxx >> Subnet Mask . . . . . . . . . . . : 255.255.0.0 >> Default Gateway . . . . . . . . . : 151.164.184.xxx > > huh? > > only way this could work would be if it was marked as "point to point" > I think.. > >> DHCP Server . . . . . . . . . . . : 192.168.1.xxx >> DNS Servers . . . . . . . . . . . : 192.168.1.xxx >> >> Can anyone tell me how they managed to get this to work in Windows, >> and suggest where to look to get it working in FreeBSD? >> >> >> Doug >> ATT uses PPPoE on their modems. Did your router have any special PPPoE settings? jim ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Wacky DHCP values that work in windows but not in FreeBSD
security wrote: > ATT uses PPPoE on their modems. Did your router have any special PPPoE > settings? It's a two-piece thing, "their" modem and my wireless router. The wireless router and windows know what to do with the info they are handed from the modem, FreeBSD doesn't. Sorry if I wasn't clear, Doug -- Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: host(1) coredumps
vol...@vwsoft.com wrote:
> On 09/13/09 06:27, Eugene Grosbein wrote:
>> Hi!
>>
>> For 8.0-BETA3:
>>
>> % host -l grosbein.pp.ru. ns2.rucable.net.
>> ; Transfer failed.
>> /usr/local/src/lib/bind/isc/../../../contrib/bind9/lib/isc/unix/socket.c:2486:
>> REQUIREsock) != ((void *)0)) && (((const isc__magic_t *)(sock))->magic
>> == ((('I') << 24 | ('O') << 16 | ('i') << 8 | ('o')) failed.
>> zsh: abort (core dumped) host -l grosbein.pp.ru. ns2.rucable.net.
>>
>> Shoud I send PR?
>>
>> Eugene Grosbein
>
> Eugene,
>
> the attached patch works around the error for me. As this is contributed
> code, it should be fixed upstream (no need to file a PR).
Can Eugene, Volker, and anyone else affected by this please try this
very-lightly-modified version of the patch and confirm that it works?
If so, I will get this in ASAP.
Doug
--
Improve the effectiveness of your Internet presence with
a domain name makeover!http://SupersetSolutions.com/
Index: dighost.c
===
--- dighost.c (revision 198000)
+++ dighost.c (working copy)
@@ -2604,10 +2604,12 @@
if (sevent->result == ISC_R_CANCELED) {
debug("in cancel handler");
- isc_socket_detach(&query->sock);
- sockcount--;
- INSIST(sockcount >= 0);
- debug("sockcount=%d", sockcount);
+ if (query->sock != NULL) {
+ isc_socket_detach(&query->sock);
+ sockcount--;
+ INSIST(sockcount >= 0);
+ debug("sockcount=%d", sockcount);
+ }
query->waiting_connect = ISC_FALSE;
isc_event_free(&event);
l = query->lookup;
signature.asc
Description: OpenPGP digital signature
Re: host(1) coredumps
On Mon, Oct 12, 2009 at 04:59:08PM -0700, Doug Barton wrote: > Can Eugene, Volker, and anyone else affected by this please try this > very-lightly-modified version of the patch and confirm that it works? > If so, I will get this in ASAP. Yes, it works too :-) Thanks. Eugene Grosbein ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Wacky DHCP values that work in windows but not in FreeBSD
On 10/12/09 4:21 PM, "Doug Barton" wrote: > Michael K. Smith - Adhost wrote: >>> -Original Message- >>> From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd- >>> n...@freebsd.org] On Behalf Of Julian Elischer >>> Sent: Monday, October 12, 2009 4:00 PM >>> To: Doug Barton >>> Cc: freebsd-net@freebsd.org >>> Subject: Re: Wacky DHCP values that work in windows but not in FreeBSD >>> >>> Doug Barton wrote: Howdy, I usually have a wireless router connected directly to the >> AT&T/Yahoo DSL modem but last night I wanted to do some debugging so I plugged >>> my laptop directly into the modem (after powering off the modem, etc.). The values I got back from DHCP not only don't make sense, they >>> didn't work in FreeBSD at all. Dual-booting to Windows showed that the >>> values I saw from DHCP were "correct," and somehow they managed to work. Taking a closer look at the router after I plugged it back in showed the same. Dhcp Enabled. . . . . . . . . . . : Yes Autoconfiguration Enabled . . . . : Yes IP Address. . . . . . . . . . . . : 76.212.147.xxx Subnet Mask . . . . . . . . . . . : 255.255.0.0 Default Gateway . . . . . . . . . : 151.164.184.xxx >>> huh? >>> >>> only way this could work would be if it was marked as "point to point" >>> I think.. >> >> That could be a primary IP address on an interface on which your 76 >> address is a sub interface. > > Can you specify what you mean by 'that'? Sure. In Cisco world Interface GigE0/0 Ip address 151.164.184.xxx 255.255.255.252 (or whatever the mask is) Ip addres 76.212.147.1 255.255.0.0 secondary They will use the primary IP address as the default. > >> The interface will do proxy-arp when a >> traffic request comes in. Or something else! I'm not sure if this will >> work, but you could actually hard code your default gateway with a >> -hopcount 2 (or higher) and see if that works. I've not tried it on a >> live machine. Something like route add default 151.164.184.xxx >> -hopcount 5. You may have to delete the DHCP-assigned entry first. > > Ah, I didn't know about -hopcount, thanks. There was no default route > installed at all when I booted. I tried 'route add default 151...' > even though I was sure it wouldn't work, and I was not disappointed. Heh. It probably complained because you weren't on the local network. As Julian mentioned, you may be able to add the -iface should help. Also, if you wanted to test, you could add yourself on the same subnet as the default gateway. Depending on what xxx is on the 151 net, you could add an interface address in the same subnet. As an example, if the address is 50, you could add 49 and a /30 subnet mask. Another trick would be to plug the windows box back in and do an 'arp -an' and find the MAC address for the 151 (if it's available). Then, you can manually add the arp to your FreeBSD box. Mike ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Wacky DHCP values that work in windows but not in FreeBSD
On Mon, Oct 12, 2009 at 6:21 PM, Doug Barton wrote: > Howdy, > > I usually have a wireless router connected directly to the AT&T/Yahoo > DSL modem but last night I wanted to do some debugging so I plugged my > laptop directly into the modem (after powering off the modem, etc.). > > The values I got back from DHCP not only don't make sense, they didn't > work in FreeBSD at all. Dual-booting to Windows showed that the values > I saw from DHCP were "correct," and somehow they managed to work. > Taking a closer look at the router after I plugged it back in showed > the same. > > Dhcp Enabled. . . . . . . . . . . : Yes > Autoconfiguration Enabled . . . . : Yes > IP Address. . . . . . . . . . . . : 76.212.147.xxx > Subnet Mask . . . . . . . . . . . : 255.255.0.0 > Default Gateway . . . . . . . . . : 151.164.184.xxx > DHCP Server . . . . . . . . . . . : 192.168.1.xxx > DNS Servers . . . . . . . . . . . : 192.168.1.xxx > > Can anyone tell me how they managed to get this to work in Windows, > and suggest where to look to get it working in FreeBSD? > > > Doug > Without seeing the actual tcpdump of the dhcp packets, I would guess that this is the Classless Static Route option in DHCPv4 (option 121). See: http://www.rfc-editor.org/rfc/rfc3442.txt http://www.iana.org/assignments/bootp-dhcp-parameters/ But tcpdump before dhclient initialization of the interface should show what options are in play (I could be wrong on option 121) tcpdump -vvv -i em0 port bootpc Good Luck. ---Dave H ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Wacky DHCP values that work in windows but not in FreeBSD
David Horn wrote: > Without seeing the actual tcpdump of the dhcp packets, I would guess > that this is the Classless Static Route option in DHCPv4 (option 121). Ok, I will give the tcpdump option a go as soon as I have a chance. Meanwhile, if this is in fact the case how would we make it work in FreeBSD? Is there a newer version of DHCP that handles this properly? Doug -- Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Wacky DHCP values that work in windows but not in FreeBSD
On Tue, Oct 13, 2009 at 1:31 AM, Doug Barton wrote: > David Horn wrote: >> Without seeing the actual tcpdump of the dhcp packets, I would guess >> that this is the Classless Static Route option in DHCPv4 (option 121). > > Ok, I will give the tcpdump option a go as soon as I have a chance. > > Meanwhile, if this is in fact the case how would we make it work in > FreeBSD? Is there a newer version of DHCP that handles this properly? I thought that dhclient originated from ISC, but looking at the 4.1.1b2 ISC DHCP source and at the OpenBSD dhclient, I did not see option 121 handling in dhclient. The freebsd copy of both dhclient.c, and /sbin/dhclient-script there is code for handling this option. I guess the FreeBSD version split from the ISC version at some point, and option 121 handling was added (2+ years ago). As far as fixing/debugging, it all depends on the exact dhcp options and values. It might just be a tweak to /sbin/dhclient-script, or it may be more complicated. http://www.freebsd.org/cgi/cvsweb.cgi/src/sbin/dhclient/dhclient.c Revision 1.21: download - view: text, markup, annotated - select for diffs Fri Feb 9 17:50:26 2007 UTC (2 years, 8 months ago) by emaste Branches: MAIN CVS tags: RELENG_7_BP, RELENG_7_0_BP, RELENG_7_0_0_RELEASE, RELENG_7_0 Branch point for: RELENG_7 Diff to: previous 1.20: preferred, colored Changes since revision 1.20: +68 -0 lines Implement RFC3442, the Classless Static Route option. The original DHCP specification includes a route option but it supports only class-based routes. RFC3442 adds support for specifying the netmask width for each static route. A variable length encoding is used to minimize the size of this option. PR: bin/99534 Submitted by: Andrey V. Elsukov Reviewed by:brooks ---Dave H ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
