Tuesday, October 30, 2012
Monday, October 29, 2012
Thursday, October 25, 2012
Wednesday, October 24, 2012
arping utility in Linux
The arping utility is part of the iputils-arping package in Debian like systems.
It is very useful for finding out if an IP number is already taken in a local network.
The syntax should be:
~$ arping -D -I eth0 -c 3 172.17.12.228
ARPING 172.17.12.228 from 0.0.0.0 eth0
Sent 3 probes (3 broadcast(s))
Received 0 response(s)
No IP in this case.
~$ arping -D -I eth0 -c 3 172.17.12.222
ARPING 172.17.12.222 from 0.0.0.0 eth0
Unicast reply from 172.17.12.222 [00:21:70:6A:EA:48] 0.754ms
Sent 1 probes (1 broadcast(s))
Received 1 response(s)
One IP found.
-D Duplicate address detection mode (DAD). See RFC2131, 4.4.1. Returns 0, if DAD succeeded i.e. no replies are received.
Monday, October 22, 2012
The Joel Test
The Joel Test
- Do you use source control?
- Can you make a build in one step?
- Do you make daily builds?
- Do you have a bug database?
- Do you fix bugs before writing new code?
- Do you have an up-to-date schedule?
- Do you have a spec?
- Do programmers have quiet working conditions?
- Do you use the best tools money can buy?
- Do you have testers?
- Do new candidates write code during their interview?
- Do you do hallway usability testing?
Solaris host unable to join multicast groups
An IGMPv2 Membership Request packet is described in RFC 3376.
IGMP messages are encapsulated in IPv4 datagrams, with an IP protocol number of 2. Every IGMP message described in this document is sent with an IP Time-to-Live of 1, IP Precedence of Internetwork Control (e.g., Type of Service 0xc0), and carries an IP Router Alert option in its IP header
The Router Alert option is described in RFC 2113.
The option type field is sub-divided into a one bit copied flag, a two bit class field, and a five bit option number. These taken together form an eight bit value for the option type field.
Copy Class Number Value Name Reference
---- ----- ------ ----- ------------------------------- ------------
1 0 20 148 RTRALT - Router Alert [RFC2113]
In binary: 1 00 10100
In Solaris 10 an IGMP multicast join packet has the IP options section with an hexadecimal value of:
00 04 00 00
It should be:
94 04 00 00
In Solaris 10, IGMP V2 membership report packets have a) a RFC non-compliant IP options header and b) the IP options header is unnecessary.
When a multicast router sends an IGMP V2 query (normally having IP option 148 (router alert) set), a Solaris 10 box replies with IGMP V2 reports for all multicast groups the box want to receive.
The IGMP packets generated by Solaris 10 contain an IP option header which is in two respects wrong:
a) as there is no "meaningful" option present (only the option "end of option list", abbreviated EOL or EOOL), there should be no IP option header present in the packet
b) If the option header is still present (because of other IP options), the last four bytes should carry the value "00 01 01 01" instead of value "00 04 00 00" , as the option number 00 means "end of options list", is a one-byte value and should be padded with 01 (NOP).
The bug is fixed in Sun's IDR hotfix 123621-01 (requires kernel patch 118833-18). Afterwards, a Solaris 10 box sends IGMP messages with the correct "router alert" IP option set, thats 94 04 00 00.
References:
RFC2236: http://tools.ietf.org/html/rfc2236
RFC2113: http://tools.ietf.org/rfc/rfc2113.txt
IANA IP Options Numbers: http://www.iana.org/assignments/ip-parameters
https://forums.oracle.com/forums/thread.jspa?threadID=1948503&tstart=345
IGMP messages are encapsulated in IPv4 datagrams, with an IP protocol number of 2. Every IGMP message described in this document is sent with an IP Time-to-Live of 1, IP Precedence of Internetwork Control (e.g., Type of Service 0xc0), and carries an IP Router Alert option in its IP header
The Router Alert option is described in RFC 2113.
The option type field is sub-divided into a one bit copied flag, a two bit class field, and a five bit option number. These taken together form an eight bit value for the option type field.
Copy Class Number Value Name Reference
---- ----- ------ ----- ------------------------------- ------------
1 0 20 148 RTRALT - Router Alert [RFC2113]
In binary: 1 00 10100
In Solaris 10 an IGMP multicast join packet has the IP options section with an hexadecimal value of:
00 04 00 00
It should be:
94 04 00 00
In Solaris 10, IGMP V2 membership report packets have a) a RFC non-compliant IP options header and b) the IP options header is unnecessary.
When a multicast router sends an IGMP V2 query (normally having IP option 148 (router alert) set), a Solaris 10 box replies with IGMP V2 reports for all multicast groups the box want to receive.
The IGMP packets generated by Solaris 10 contain an IP option header which is in two respects wrong:
a) as there is no "meaningful" option present (only the option "end of option list", abbreviated EOL or EOOL), there should be no IP option header present in the packet
b) If the option header is still present (because of other IP options), the last four bytes should carry the value "00 01 01 01" instead of value "00 04 00 00" , as the option number 00 means "end of options list", is a one-byte value and should be padded with 01 (NOP).
The bug is fixed in Sun's IDR hotfix 123621-01 (requires kernel patch 118833-18). Afterwards, a Solaris 10 box sends IGMP messages with the correct "router alert" IP option set, thats 94 04 00 00.
References:
RFC2236: http://tools.ietf.org/html/rfc2236
RFC2113: http://tools.ietf.org/rfc/rfc2113.txt
IANA IP Options Numbers: http://www.iana.org/assignments/ip-parameters
https://forums.oracle.com/forums/thread.jspa?threadID=1948503&tstart=345
Subscribe to:
Posts (Atom)